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CHAPTER 1 

INTRODUCTION TO ULCnet 
and the 
ULC-OPSnet OPERATING SYSTEM 



GENERAL 

You have purchased a complete networking system for the 
KAYPRO Models 2, 4, 10, and Robie line of microcomputers. Most 
other Z80 based CP/M(c) microcomputers may be added to the net- 
work as long as they are equipped with a RS-232C serial port 
driven by a Zilog SIO PUSART (or equivalent) and capable of 
transmitting and receiving synchronously. The software and hard- 
ware to connect many other brands of microcomputers to your 
ULCnet(c) may be special ordered from your KAYPRO dealer. 

COMPONENTS 

The networking components are divided into three groups: 
(1) the KAYNET/ULCnet Connector Adapter PCB's (hardware), (2) the 
network media, i.e., the four conductor telco cable, RJ-11 
terminators and RJ-11 tap sockets, and (3) the ULC-OPSnet(c) 
network operating system (software) contained on diskettes. 
Chapter 2 is devoted to the installation and operation of the 
KAYNET/ULCnet Connector Adapter PCB's and network media while the 
remainder of the chapters are devoted to installing and using the 
network operating system. 

NOTE: All Figures (illustrations and tables) are contained 
in Appendix i and are appropriately referenced in the 
text of this manual. 

Once the network wire and tap sockets have been installed, 
the KAYNET/ULCnet Connector Adapter PCB's have been connected to 
both the network and to their respective microcomputers, and the 
microcomputers have been powered up, the ULC-OPSnet software is 
ready to be installed. Once the software is completely installed 
(see Chapters 3 and 4) the entire network is ready for use. 

FEATURES 

ULC-OPSnet provides the ability to assign any remote pe- 
ripheral devices on the network as local devices for a particular 
workstation. Therefore, programs may be executed, files may be 
opened, processed, copied and, listed by any station on the net- 
work, even though they may reside on any other station on the 
network. A remote printer may be accessed from any station, and 



(c) - Signifies trademark and/or copyright . 

ULCnet is a registered trademark of Orange Compuco, Inc. 

OPSnet is a registered trademark of Aquinas, Inc. 

CP/M is a registered trademark of Digital Research, Inc. 
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since printing operates in the background mode, the station to 
which the printer is attached is available for processing while 
the printer is operating. Disk i/o serving also operates in 
background mode. Thus an operator may be processing at Station 
#1 while other stations on the network are being serviced by the 
disk drives attached to Station #1. 

Messages may be sent from one station to another. They are 
displayed on the destination station's console device, or if that 
station is busy, electronic mail may be employed such that mes- 
sages queue up in a station's "mail box." 

Complete security is provided by a comprehensive access 
security system, limiting system use with a combination of 
passwords, privilege levels, and user identification numbers 
(USER ID's). The system further permits files to be designated 
"private" or "sharable" and "locked" or "unlocked." A facility is 
also provided which will support a dynamic file lock status for 
multi-user applications. 

The command structure for ULC-OPSnet is discussed beginning 
with Chapter 5. ULC-OPSnet supports three classes of commands: 

1. The General Commands 

2. The Network Commands 

3 . The Enhanced CP/M Commands 

COMMANDS 

This User's Guide is concerned with the use of the General and 
Network commands which provide for using the operating system and 
maximizing the use of network concepts. The ULC-OPSnet operating 
system interprets CP/M commands and all CP/M commands are avail- 
able as described in your CP/M manual. Enhanced versions of these 
same CP/M commands which are described in Chapter 9 are available 
under ULC-OPSnet and may be used without leaving ULC-OPSnet. The 
technical distinctions between the CP/M commands and their en- 
hanced counterparts in ULC-OPSnet are discussed in the ULC-OPSnet 
Technical Manual. 



MEMORY REQUIREMENTS 

As a general rule, any application program which operates 
under CP/M and which requires up to 7K bytes of storage less than 
the TPA for your current CP/M operating system will run under 
ULC-OPSnet. The standard TPA size for the KAYPRO Models 2 and 4 
is 56K. Thus, the useable TPA for the KAYPRO Models 2 and 4 with 
ULC-OPSnet is 49K. The useable TPA for the KAYPRO Model 10 with 
ULC-OPSnet is 48K. 
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SOFTWARE 

The ULC-OPSnet software is distributed in two versions: 

1 . The Gatekeeper software 

2. The Workstation software 

Each of these versions is distributed on a diskette. Both Gate- 
keeper and Workstation software are distributed on a double- 
density 5-1/4" diskette. The content of the User's Guide for 
each version is identical. One Gatekeeper version is required 
per network while the number of Workstation versions required is 
equal to the number of stations to be placed on the network minus 
one (the Gatekeeper counts as one workstation). The Gatekeeper 
software may reside on either a hard disk or a floppy disk system, 

GATEKEEPER SOFTWARE 

ULC-OPSnet provides that one station on the network is to be 
designated as the Gatekeeper. In addition to the standard Work- 
station software, the systems disk for the Gatekeeper station 
contains additional software routines which perform network 
management functions. A station on the network may become the 
Gatekeeper merely by using the Gatekeeper systems disk on that 
station. 

The functions of the Gatekeeper are: 

1. Permits the Gatekeeper operator to determine which 
operators and which functions are active on the network 
at any time. 

2. Checks that all station identification numbers 
(entered during network operations) are unique. 

3. Manages the assignment and/or modification of all user 
numbers, passwords, and privilege levels for all opera- 
tors on all stations. 

4. Provides an affirmative response to a remote station's 
inquiry as to the presence of a Gatekeeper. 

5. Checks that all serial numbers on the various worksta- 
tions are unique. 



WORKSTATION SOFTWARE 

ULC-OPSnet is provided on a system diskette configured for 
the particular brand of workstation to be used. Each system 
diskette contains a unique encrypted serial number. The Worksta- 
tion software contains all of the ULC-OPSnet system software 
described herein with the exception of the Gatekeeper software. 
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ULC-OPSnet is independently installed on each workstation. 
User numbers, passwords, and privilege levels unique to the 
operators of a given station are assigned during that station's 
installation phase. When attempting to bring up a workstation on 
the network, ULC-OPSnet requires that the Workstation software 
first check the network for the presence of a Gatekeeper. Upon an 
affirmative response, the Workstation software continues the 
initialization function. 



SELF CLOCKING OPERATION 

The KAYPRO Models 2, 4 and 10 each utilize a Zilog SIO 
PUSART as the serial port controller chip. The Zilog SIO gen- 
a clock sync pulse capable of providing communications at 
synchronous baud rates of up to 307. 2K baud. The KAYNET/ULCnet 
Connector Adapter PCB for the KAYPRO Models 2, 4 and 10 runs in 
the synchronous mode. A switch is provided next to the KAYNET 
RJ-11 jack to either the Networkorthe communications serial 
port . 

SOFTWARE UPDATES AND ASSISTANCE 

Prior to opening the package containing this manual, you 
were asked to read the attached License Agreement which describes 
the terms under which this software may be used. Included with 
the License Agreement is the Software Registration Card. At this 
point, please fill out the card and mail as indicated. Unless the 
Software Registration Card is on file, you will not receive 
software updates or be entitled to participation in the software 
performance program. Note that a Software Registration Card is 
required for each package of software purchased. If, after 
following the instructions in this manual, you have any problems 
with the software, please complete the Software Performance 
Report and mail as indicated. Problems with hardware items should 
be brought to the attention of your dealer. 



WHAT THIS PACKAGE CONTAINS 

You should have purchased one Gatekeeper software package 
and the number of Workstation software packages equal to the 
number of workstations you intend to network minus one (the 
Gatekeeper counts as one workstation). Check that the Gatekeeper 
version contains a diskette marked "GATEKEEPER VERSION" and that 
each Workstation version contains a diskette marked "WORKSTATION 
VERSION." Report any discrepancies to your dealer. 



1-4 



OTHER NECESSARY EQUIPMENT 

You should also have purchased one KAYNET/ULCnet Connector 
Adapter Kit for each KAYPRO computer to be placed on the network. 
The carton containing the Connector Adapter Kit should include: 

1 - KAYNET/ULCnet Connector Adapter PCB. 
1-6' Interconnect cable (RJ11). 
1 - Tap socket (RJ11). 

1 - KAYNET Bulkhead RJ11 socket/ switch housing. 

2 - Signal harnesses. 
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CHAPTER 2 
THE ULCnet CONNECTOR ADAPTER 



INSTALLATION 

The ULCnet Connector Adapter is a transceiver device 
designed to interface the serial RS-232C port of a Z80 based 
microcomputer which runs the CP/M operating system to a network 
whose medium is a four-conductor telco cable. Connections to the 
network wire are made via common RJ-11 plugs and tap sockets 
which are readily available from your dealer or any electronics 
supply house. 

The tap sockets at either end of the network must be termi- 
nated in order to provide for a balanced line. These special 
terminated tap sockets may be purchased from your dealer or made 
up from ordinary tap sockets as shown in Figure 2-1. 

The total length (terminator-to-terminator) of the network 
wire may be up to 2,500 feet, with 7 or fewer Connector Adapters 
attached, or up to 1,000 feet with the maximum 64 Connector 
Adapters attached. Common RJ-11 tap (in-line) sockets are used 
to tap into the network wire at any convenient location. To 
install a tap socket, first pry off the cover which exposes 12 
connector lugs (6 on each side of the RJ-11 socket) and proceed 
as follows: 

IMPORTANT NOTE; ULCnet utilizes low-cost, unshielded telco 
wire. This reduces overall cost of implementation and makes 
ULCnet "user installable." To comply with FCC regulations, 
ULCnet generates a very low energy signal. The signal recei- 
vers inside of the ULCnet connector adapter are thus suscep- 
tible to some outside interference, such as fluorescent 
ballast transformers and AC induction motors. Please make 
certain that the network wire is at least 12" away from any 
fluorescent lights and air-conditioning fan motors. Other- 
wise, network performance may be degraded by forced packet 
retransmissions . 

1. Lay out the network wire along the floor next to the 
baseboard. The network wire may be strung inside walls, 
over the ceiling or in any convenient fashion to reach 
all offices in which there will be network connections. 

2. Starting at one end of the network, install a terminator 
tap socket at the physical end of the network wire 
first. It is not necessary to strip the colored 
sheathing and expose the bare copper wire. Push the 
ends of each colored wire (corresponding to the color of 
the internal wires soldered to each bank of four lugs) 
into an available lug, using the tip of a needle-nose 
pliers (see Figure 2-2). The lugs are self-stripping. 
Fasten terminator tap to wall with screws provided and 
snap on the cover. 
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3. Mount (staple) the network wire along the baseboard to 
the next desired tap point. Cut the wire. Strip outer 
sheathing leaving about 1-1/2" of the four colored wires 
exposed. Similarly, strip about 1-1/2" of the outer 
sheathing from the unstapled end of the network wire. 

4. Push corresponding colors of wire onto available lugs 
with the tip of a needle-nose pliers. Do this for the 
four wires coming into the tap socket and the four wires 
leaving the tap socket (see Figure 2-2). Note that the 
standard ULCnet tap has two available lugs for each of 
the four colors. The terminator tap has only one avail- 
able lug for each color (the other lug on the terminator 
tap is used for the termination resistor). Fasten tap to 
wall with screws provided and snap on the cover. 

5. Continue as above until all desired taps are installed. 
The final tap in the network must be a terminator . 

Note: A proper installation of the physical network media 
is critical to system performance. Tap sockets should 
be permanently mounted to avoid dangling wires sub- 
ject to breaking. Although not mandatory, a good 
practice is to solder the wires to the lugs after the 
locations have been finalized. 



Line balance on the completed network may be checked with an 
accurate VOM. Resistance measurements should be taken between the 
red and black wires (Net A) and between the yellow and green 
wires (Net B). The following table shows the range of resistance 
values for standard 4 conductor telco wire which should appear 
for various lengths of network. Measurements are taken w ithout 
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INSTALLING THE KAYNET/ULCnet NETWORK CIRCUIT BOARD 

The KAYNET/ULCnet NCB (Network Circuit Board) for KAYPRO 
models with the universal mother board contains all of the Net- 
work circuitry, harness connecting pins, and a forty (40) pin IC 
socket. This NCB must be properly installed in order for ULCnet 
and the computer's keyboard to operate. The installation proce- 
dure involves removing the cover of the KAYPRO computer, removing 
an SIO chip from its socket, seating the SIO into the socket on 
the NCB, and plugging the NCB back into the SIO socket on the 
main board. It is very important that the user exercise care in 
removing and replacing the SIO chip so that the pins do not bend 
and so that all pins seat properly in the socket. After the NCB 
is properly seated, all of the signal and power harnesses must be 
properly installed. 



PROCEDURE FOR ALL KAYPRO MODELS WITH UNIVERSAL BOARD 

Installing the Network Circuit Board 

Unplug the computer. Remove the cover by removing the 10 small 
Phillips-head screws. Facing the front of the chassis, locate the 
SIO device #U11 (see figure 2-3). Note that there are two SIO's 
in the KAYPRO, and that the SIO's may have some designation other 
than SIO printed on them. Be certain you have located the one 
marked Ull on the main circuit board. Carefully remove the SIO 
from its socket by sliding a small screwdriver under each end of 
the chip and applying even, slight pressure. Locate the "c_" mark 
and the pin 1 mark on the NCB. Line up the "key" of the SIO with 
the "c" mark on the NCB, and fir mly seat all 40 pins of the SIO 
into the socket on the Network Circuit Board (see figure 2-3). 
Line up the pins in the Network Circuit Board with the "key" of 
the SIO socket on the main circuit board in the same orientation 
as it was before removal. Firmly seat the NCB into socket Ull by 
applying even pressure from the top and steadying the main cir- 
cuit board from underneath (see figure 2-3). Hold the spacer 
underneath the hole at the right front of the NCB. Inset the #6 
screw through the top of the hole, and firmly seat the spacer in 
place. 

Installing the KAYNET Bulkhead Tap Connector 

The KAYNET bulkhead tap connector attaches to the rear of the 
computer through the air vents with two screws provided. Route 
the harness leading from the KAYNET tap along the right side of 
the main board to the front right-hand side of the NCB. The 
connector on the other side of the harness is "keyed" with an 
insert in one hole. Line the harness connector up with the "key" 
facing the cut-off pin, and inset the connector into the pins at 
connection point P3 (see figure 2-3). In the same manner, insert 
the connector from the two-wire harness into the pins at con- 
nection point P4. Gently remove the harness from the POWER 
LED, and insert the connector at the other end of the two wire 
harness, noting the polarity. 
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Installing the Power Harness 

The other harness provided is a power harness, easily identified 
by the larger gauge wire and connectors. Gently remove the power 
harness connector to the main board, and plug it into the rear 
power connector on the NCB. Now, plug one end of the power har- 
ness provided into the other power connector on the NCB, and the 
other end into the power connector on the main board (see figure 
2-3). 

Replace the cover, lining up the screw holes with the openings. 
Replace the Phillips-head screws. This completes the instal- 
lation on this unit. 

Once the network wire has been installed (typically around the 
baseboard of an office) and the tap sockets have been mounted at 
designated locations, the KAYNET bulkhead tap connectors may be 
plugged into the tap sockets via the interconnect cables (a six- 
foot interconnect cable is supplied with each NCB). 

OPERATION 

Switch on power to each of the KAYPRO computers connected to the 
network. The POWER LED should now light as it did before instal- 
lation of the NCB. When there is no ULCnet activity, the POWER 
LED should light steadily. When data is transferred on ULCnet, 
the POWER LED will flicker with each data packet. When network 
activity is very high, the POWER LED will appear to dim and may 
even momentarily cease to light. As you become more familiar with 
its operation, you will be able to use the POWER LED as a rough 
indication of what kind of activity is occurring on ULCnet. 

Now, boot each KAYPRO computer and execute some keyboard opera- 
tion (like a DIR command) to make certain the NCB and its SIO 
were properly installed. If the POWER LED remains lit, and the 
keyboard is responsive, the NCB was most probably installed 
correctly. 

The switch on the KAYNET bulkhead tap connector should be in the 
NET position. In this position, signal connection to the serial 
data I/O port is disabled, and the ULCnet connection is enabled. 
Likewise, if the switch is in the COMM position, ULCnet I/O is 
disabled to the station, and the serial data I/O port is enabled. 
Keep the switch in the NET position during the remainder of the 
installation phase. 
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CHAPTER 3 
GETTING STARTED 



GENERAL CARE OF DISKETTES 

Depending on the type of computer equipment purchased, you 
will be using either 5-1/4" or 8" floppy diskettes. These disket- 
tes may be single or double-sided (information may reside on one 
or both sides) and single or double-density (refers to the amount 
of information which may be recorded). You need not concern 
yourself with these designations as long as you use the appro- 
priate diskettes specified by the manufacturer for a particular 
workstation. The format of the information to be recorded on the 
diskette also varies from manufacturer to manufacturer so that 
one 8" floppy diskette will not work on all workstations having 
8" disk drives. The same is true for the 5-1/4" floppy disk- 
ettes. A good practice is to record the type of equipment on each 
diskette label. 

In general, handle diskettes carefully, using the same pre- 
cautions you use with tape cassettes and high-fidelity records. A 
small indentation, dust particle, or scratch can render all or 
part of a diskette unreadable — permanently. 

Keep the diskette in its storage envelope whenever it is 
not in one of the drives. 

Do not place a diskette in the drive while you are 
turning the system on or off. 

Keep diskettes away from magnetic fields (transformers, 
AC motors, magnets, TVs, radios, etc.). Strong magnetic 
fields will erase data stored on a diskette. 

Handle diskettes by the jacket only. Do not touch any of 
the exposed surfaces. Do not try to wipe or clean the 
diskette surface; it scratches easily. 

Keep diskettes out of direct sunlight and away from heat. 

Avoid contamination of diskettes with cigarette ashes, 
dust, or other particles. 

Do not write directly on the diskette jacket with a hard 
point device such as a ball point pen or lead pencil; use 
a felt tip pen only. 

Store diskettes in a vertical file folder on a shelf 
where they are protected. 

In very dusty environments, you may need to provide 
filtered air to the computer room. 
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Before inserting a diskette, check the write-protect notch. 
(See Figure 3-1.) If you do not want to write to that diskette, 
it is a good idea to leave it "write-protected." This way, the 
ULC-OPSnet operating system will not let you accidentally write 
to that diskette. To write-protect a diskette, just leave the 
write-protect notch UNcovered if an 8" diskette, and covered if a 
5-1/4" diskette. 

If you do want to write to the diskette, cover the write 
protect notch with gummed-foil tape provided with the diskette if 
an 8" diskette, and REmove the foil tape if a 5-1/4" diskette. 

Any alteration of the data on the diskette — even the dele- 
tion of data or programs — requires that the diskette not be 
write-protected. (Cover the notch with gummed-foil tape - 8" 
diskette; uncover - 5-1/4" diskette.) 

All diskettes will wear out after continued use. It is 
vitally important that you make a working copy of the system 
diskettes supplied with each of your software packages. Refer to 
your CP/M manual for the method of formatting and backing up 
system diskettes. After the copies are made, replace the origi- 
nals in a safe place for future copies if necessary. 

In the following examples, the "NET READY" light refers to 
the POWER LED on KAYPRO computers containing the NCB. 

INSTALLING THE ULC-OPSnet OPERATING SYSTEM 

For the initial installation follow the instructions below 
precisely. The operating system may be reinstalled at any time 
should you wish to change some or any of the system attributes. 
Screen formats will appear as an outlined rectangle. What you are 
to type will appear in BOLD print. Type the commands exactly as 
they appear observing any blanks or spaces. The symbol <RET> 
means you are to press the RETURN key. Information shown in the 
screen format which is not in bold print represents responses 
from the computer. 

ULC0PSG.COM and ULC0PS.COM, the main program modules, are 
actually distributed on each diskette by KAYPRO. ULC0PS.COM is 
Workstation software and ULC0PSG.COM is Gatekeeper software. 
Both the Workstation and Gatekeeper modules have common utility 
programs such as MAIL.COM, SEND.COM, etc. Only one system in the 
network may have Gatekeeper software loaded. The Gatekeeper 
software is usually reserved for use by the installation manager, 
company controller, or other manager. Both Gatekeeper and Work- 
station can have access to all systems on the network, but only 
the Gatekeeper can control access to the network and can view the 
status of the network. These features are more fully explained 
in Chapter 4. It would be best to decide now which system in the 
network will have the Gatekeeper software. If you are installing 
ULC-OPSnet on a KAYPRO 10 or 12, please refer to the installation 
section for those particular models. Note that the larger BIOS 
on the KAYPRO Models 10, 12, and 4X result in a lower TPA 
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(Transient Program Area) than is available for the Models 2, 2X, 
and 4. Note also that the following example illustrates the 
installation of Gatekeeper software. If Workstation software is 
to be installed, simply substitute ULCOPS for ULCOPSG and visa 
versa. 

PROCEDURE FOR KAYPRO MODELS 2, 2X, 4, 4X, and ROBIE 

1. Power up all microcomputers. The POWER LED, or "NET 

READY" light should be lit on all (see Chapter 2). 

2. "Boot" CP/M in each workstation according to the 
instructions contained in the CP/M manual. The screen on 
each workstation should now show the "A" disk drive 
prompt : 

+ + 

: A0> : 
+ + 

3. Select one station to serve as the Gatekeeper. This 
choice may be changed later at your convenience. 

4. Prepare a CP/M systems diskette in accordance with the 
instructions in your CP/M manual. This diskette should 
have at a minimum the following files: 

PIP.COM 
STAT . COM 
C0PY.COM 

5. Place the CP/M systems diskette in drive A: and the ULC- 
OPSnet diskette in drive B:. "PIP", or copy all of the 
ULC-OPSnet files from drive B: to drive A: using: 

+ + 

: A0>PIP A:=B:*.* [VO] <RET> : 

+ + 

Remove the ULC-OPSnet master release diskette from drive 
B: and put it in a safe place. 

6. Take a directory of the CP/M system diskette (which now 
contains the ULC-OPSnet files) on drive A. 

+ _+ 

: A0>DIR A:<RET> : 

+ + 
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In addition to the CP/M files above, at a minimum the 
following 27 ULC-OPSnet release files should be displayed: 



ACCT . SYS 
APPLNOTE . CMD 
FIND.COM 
GENULCFD.COM 
INET.COM 
LOG . COM 
MAIL.COM 
NETUTIL.COM 
OHELP . COM 



OSUB . COM 
OXSUB . COM 
PRINTOFF.SUB 
PRINTON.SUB 
PSUB . COM 
PUTULC . COM 
QUEUE . COM 
REACT . COM 
SEND.COM 



SP00L.COM 
ULCOPS.HLP 
ULCOPS . COM 
ULCOPSG . COM 
RETRY.COM 
UTIL.COM 
WHO . COM 
TEST . DBU 
TEST.NDX 



7. Now perform the following: 



A0>ERA ULCOPS. COM<RET> 

A0>REN COPYDISK.COM=COPY.COM<RET> 

A0 >ULCOPSG<RET> 

ULC-OPSnet vl . 8x Gatekeeper - Node 
OPSnet by Aquinas, Inc. Copyright (c) 1983 

<A0> LOGIN 0<RET> 

Password: 1111 (Note: **** will appear instead 
of 1111) 

Logged-in on ULC-OPSnet vl.8x Gatekeeper - Node 
OPSnet by Aquinas, Inc. Copyright (c) 1983 
[0] User: MANAGER 7000 

<A0>INET KAYPRO<RET> 

Gatekeeper running . . . 
<A0> 



8. The Gatekeeper station is now ready for operation. 
PROCEDURE FOR KAYPRO MODELS 10 and 12 

1. Power up all microcomputers. The POWER LED, or "NET 
READY" light should be lit on all computers (see Chap- 
ter 2). 

2. The KAYPRO Models 10 and 12 are shipped with "bundled" 
software in many different "USER" areas. You will find 
later in this manual a description of how the CP/M 
"USER" area is utilized by ULC-OPSnet. All of the ULC- 
OPSnet software must be in USER £0] area on the A: 
partition of the hard disk. As you later plan your 
installation, you will find it easier to place all 
shared .COM and .OV? files in USER [0] area of either 
Disk A: or Bs. Be certain that you follow the instal- 
lation procedure exactly. 
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3. 



Since it is assumed that all of the ULC-OPSnet software 
will reside on the hard disk, it is not necessary to 
prepare a floppy disk with the CP/M system on it. 

3a) "RESET" the KAYPRO system. 

3b) Exit the "Main Menu" to the standard CP/M prompt: 



A0> 



4. 



Insert the ULC-OPSnet diskette into the floppy disk 
drive (logical disk C:). 

Now perform the following: 

+ + 

: A0>PIP A:=C:*.*[VO]<RET> : 

+ + 



(A list of files transferred will be displayed. Note - 
at a minimum, this list should contain the same files 
specified in instruction 6 for the Models 2 and 4.) 

Remove the ULC-OPSnet master release diskette and put it 
in a safe place. 

Now perform the following: 

+ + 

A0>ERA ULCOPS.COM<RET> 

A0 > ULCOPSG<RET> 

ULC-OPSnet vl.8x Gatekeeper - Node 

OPSnet by Aquinas, Inc. Copyright (c) 1983 

<A0>LOGIN 0<RET> 

Password: 1111 (Note: **** will appear instead 

of 1111) 
Logged-in on ULC-OPSnet vl.8x Gatekeeper - Node 
OPSnet by Aquinas, Inc. Copyright (c) 1983 
[0] User: MANAGER 7000 

<A0>INET KAYPRO<RET> 

Gatekeeper running... 
<A0> 

+ + 

8. The Gatekeeper software is now ready for operation. 

INSTALLING THE ULC-OPSnet WORKSTATION 

At this time it is a good idea to identify each workstation 
with a unique identification character. The Gatekeeper station is 
always automatically specified "G". Workstation identification 
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characters (hereafter called "Station ID" or "Node ID") may be 
any single ASCII character except for "G" (the Gatekeeper), "0" 
(reserved for specifying a workstation as "local"), or ASCII 
characters appearing in BRACKETS ([]) on page 8-6. The following 
instructions for installing the workstation software must be 
performed for each workstation on the network. 

1. As with Gatekeeper installation, installations of the 
Workstation software require a slightly different pro- 
cedure depending upon whether it is installed on a Model 
2/4, or on a Model 10/12. 

2. Prepare CP/M systems diskettes for each workstation on 
the network in accordance with the instructions in your 
CP/M manual. Each of these diskettes should have at a 
minimum the following files: 

PIP.COM 
STAT . COM 
COPY . COM 

3. For each Workstation, place a CP/M system diskette in 
drive A, a ULC-OPSnet diskette in drive B, and copy the 
ULC-OPSnet files from drive B to drive A using: 

+ + 

: A0>PIP As=B:*.* [VO]<RET>: 

+ + 



4. 



Remove the ULC-OPSnet diskette and put it in a safe 
place. Remember to record the serial number of the ULC- 
OPSnet diskette used each time so that serial numbers 
are not duplicated in the Network environment. 

For each workstation, take a directory of the CP/M 
systems diskette (which now contains the ULC-OPSnet 
files) on drive A. 



: A0>DIR<RET> 

+ 



In addition to the CP/M files above, at a minimum the 
following 27 ULC-OPSnet release files should be displayed: 



ACCT . SYS 
APPLNOTE . CMD 
FIND.COM 
GENULCFD.COM 
INET.COM 
LOG . COM 
MAIL.COM 
NETUTIL.COM 
OHELP . COM 



0SUB.COM 
OXSUB . COM 
PRINTOFF.SUB 
PRINTON.SUB 
PSUB.COM 
PUTULC . COM 
QUEUE . COM 
REACT . COM 
SEND . COM 



SP00L.COM 
ULCOPS . HLP 
ULCOPS . COM 
ULC0PSG.COM 
RETRY.COM 
UTIL.COM 
WHO . COM 
TEST.DBU 
TEST . NDX 
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5. Now perform the following: 



A>ERA ULCOPSG.COM<RET> 

A>REN COPYDISK.COM=COPY.COM<RET> 

A>ULCOPS<RET> 

ULC-OPSnet vl . 8x Workstation - Node 
OPSnet by Aquinas, Inc. Copyright (c) 1983 

<A0> LOGIN 0<RET> 

Password: 1111<RET> (Note: **** will appear 

instead of 1111) 
Logged-in on ULC-OPSnet vl . 8x Workstation - Node 
OPSnet by Aquinas, Inc. Copyright (c) 1983 
[0] User: MANAGER 7000 

<A0>INET KAYPRO <Node ID><RET> 

Net Ready 
<A0> 



The procedure for the KAYPRO Models 10 and 12 is likewise 
similar to the procedure for the Gatekeeper on the 10 and 12, 
with the exception that the file erased is ULCOPSG.COM and the 
file to be loaded is ULC0PS.COM. The ULC-OPSnet operating system 
will automatically relocate itself to accomodate the system's 
BIOS; i.e., ULC-OPSnet will know what kind of system it is 
running on. 

TESTING THE NETWORK 

After the Gatekeeper and all of the workstations have been 
installed as above, the network is ready for testing. The 
following tests assume that a network is composed of three 
stations— a Gatekeeper, Workstation #1 and Workstation #2 (you 
may have used designations other than 1 and 2. If so, substitute 
your station identifiers for those used in the tests). 

1. At the Gatekeeper station, do the following: 

+ + 

<A0>SEND 1 I AM THE GATEKEEPER<RET> 



2. 



<A0>SEND 2 HELLO<RET> 

<A0>SEND ALL GOOD MORNING<RET> 

+ + 

At Station #1, the following should appear on the 
screen: 



+ + 

: <A0>;;Msg from node G-l I AM THE GATEKEEPER : 
: ;;Msg from node G - ALL GOOD MORNING : 

+ + 
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At Station #2, the following should appear on the 
screen: 



<A0>;;Msg from node G-2 HELLO 

;;Msg from node G - ALL GOOD MORNING 



At Station #1, do the following: 



<RET> 

<A0>SEND ALL GOOD MORNING TO ALL<RET> 

<A0> 



At Station #2, the following should appear: 



: ; ; Msg from node 1 - ALL GOOD MORNING TO ALL 

+ 



6. At Station #2, do the following: 



<RET> 

<A0>SEND G I AM NODE 2<RET> 

<A0> 



REVIEW 



At the Gatekeeper Station the following should appear: 

+ + 

: <A0>;;Msg from node 1 - ALL GOOD MORNING TO ALL : 

: ; ; Msg from node 2 - G I AM NODE 2 : 

+ + 



Thus far, you have been introduced to the procedures for 
bringing up the network, logging on the system with a user 
identification number, and supplying a password to gain access. 
You have also been introduced to the concept of sending messages 
over the network. 

Before going any further, you should become familiar with 
the use of user identification numbers, passwords, and privi- 
leges. Chapter 4 covers these concepts. 

From this point on, the User's Guide will refer to the 
"system prompt" as a starting point for all operations. You have 
already seen the system prompt: 



<A0> 



•>USER ID - corresponds to CP/M user area function. 
•>Currently logged disk drive. 
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In the above example the system prompt tells us that user has 
logged on the system and drive A is the currently logged disk 
drive. Whenever ULC-OPSnet is first loaded via the ULCOPS com- 
mand, the currently logged disk drive will be A. To change the 
currently logged disk to B, simply type: 

+ + 

: <A0>B:<RET> : 

+ + 

The computer will respond with: 

+ + 

: <B0> : 

+ + 



if you are logged in as "USER 0." 

In the previous test examples, stations 1 and 2 were "logged 
in" as USER [0]. Each of them could also have been logged in as 
USER [1], since Passwords are provided on the release diskette 
for logging in as both USER [0] and USER [1]. Try the following 
on Workstation (Node) 1: 

+ + 

< A0 >LOGOUT<RET> 

Logged-out of ULC-OPSnet vl.8x Workstation -Node 1 

OPSnet by Aquinas, Inc. Copyright (c) 1983 

<A0> LOGIN 1<RET> 

Password: DEMO<RET> (Note: **** will appear 

instead of DEMO) 

Logged-in on ULC-OPSnet vl . 8x Workstation - Node 1 
OPSnet by Aquinas, Inc. Copyright (c) 1983 
[1] User: USER 1001 

<A1> 



The significance of LOGIN USER [ID], Passwords, and other 
aspects of the ULCnet security system will be explained in Chap- 
ter 4. You will discover that the ACCT.SYS file for each system 
as shipped allows a Privilege Level of "7" for USER [0] (fully 
privileged) and a Privilege Level of "1" for USER [1] (minimum 
privileges). Thus if you logged in as USER [1] above, you would 
be able to send messages and queue files to other printers, but 
you would not be able to get to files located on other systems in 
the network. It is very important to thoroughly read and 
understand the examples in the remaining chapters of this manual 
before attempting to place ULCnet in an operational mode. 
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CHAPTER 4 
NETWORK ENVIRONMENT, SYSTEM ACCESS AND FILE SECURITY 



INTRODUCTION 

Now that you have successfully installed the network it is 
necessary to consider how to best utilize the network in your 
day-to-day environment. First you must understand that ULCnet 
creates a new and totally different environment. On the one hand 
all of the standard CP/M commands and features are implemented, 
and, with the exception of the "<A0>" prompt instead of the "A>" 
prompt, you will notice very little difference in running 
programs under ULC-OPSnet versus running programs under CP/M. 
What is_ different about the ULCnet environment, and what must be 
planned for in your operational routine, is that: 

1. Every station on the network (or "node" as it is often 
called) has a small part of its memory allocated to the 
"serving partition". This is where requests for 
resources at your station from other "nodes" in the 
network are serviced. Thus while you are sitting at 
your station working, your printer could suddenly begin 
to print a file "spooled" to it from another station. 
Likewise, one of your disks could start to read or 
write because some other node in the network requested 
a file or program, or might be sending a file to your 
"mail box". 

2. Likewise, when working at your station, you are no 
longer limited to programs, data and printers located 
only at your station locally, as you are in CP/M. If a 
program (.COM) file you want to run is located on a 
floppy or hard disk drive on some other node, you may 
run that program on your system by loading it over 
ULCnet. For example, it is even possible from your 
station to execute a program where the .COM file is 
resident on, say, node 3, using data files from disks 
on nodes 8, T, and G, and printing the output file on a 
printer located at node 6. 

In short, ULCnet and the ULC-OPSnet operating system create 
a "multi-user, multi-tasking" operating environment. This new 
kind of operating environment may be likened to that of a large 
data processing department, with mainframe computers running 
various different jobs from a variety of peripheral devices and 
interfacing to a number of different terminals. The average 
utilization of each device improves because a number of tasks 
appear to use each device simultaneously. Much of what used to 
be wasted "wait" time for the microprocessor chip inside each 
micro-computer can now be utilized to drive printers and handle 
disk input and output for other stations on the network. 

With all of the flexibility and availability created by the 
ULCnet concept, more attention to the details of operating proce- 
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dure and security are required. Just as the manager of a large 
data processing installation must be concerned with how jobs are 
submitted for processing, who has access to what data, and what 
programs are permitted to be run by which people, so also must 
the manager of a ULCnet microcomputer network be concerned about 
these issues. The ULC-OPSnet operating system provides some 
state of the art security and control measures for limiting 
access to the system, access to program and data files, and for 
"presetting" an operator's system resource assignments. When 
implemented in a planned and organized manner by the individual 
responsible for management of the network, these control measures 
will provide a high level of security for data and programs as 
well as permit new, inexperienced operators to learn to use the 
system without fear of loss of critical data. 



SYSTEM ACCESS SECURITY 

In addition to providing a set of commands for networking, 
ULC-OPSnet acts as a sort of "super operating system", augmenting 
many of the functions of CP/M, replacing some functions, and 
calling CP/M for other functions. Since CP/M was designed to 
operate in a "single task, single user" environment, no thought 
was given to the design of a security access system. ULC-OPSnet, 
however, facilitates access to data, programs, and devices any- 
where in the network. Thus the first level of security in the 
network environment deals with controlling access to any part of 
the system by any potential user. After ULC0PS.COM or 
ULC0PSG.COM are first loaded, you will see the standard system 
prompt, an <A0>. Notice that an attempt to perform any system 
function will be denied, and the system will return a message 
asking the operator to LOGIN. For example, suppose you load 
ULC0PS.COM and immediately ask for a directory (remember, what 
you are to type on the keyboard is printed in bold and the 
character <RET> means to press the RETURN key: 

+ + 

A>ULCOPS<RET> 

ULC-OPSnet vl . 7x Workstation - Node 

OPSnet by Aquinas, Inc. Copyright (c) 1983 

<A0>DIR<RET> 

?Login please 

<A0> 

+ + 

Clearly, ULC-OPSnet will not process any commands until the 
operator has successfully completed the LOGIN sequence. The 
LOGIN and LOGOUT commands access the ULC-OPSnet L0G.COM module. 
You will recall from Chapter 3 that after typing LOGIN, a one 
digit number (called the "USER ID") from 0-9 had to be entered. 
The L0G.COM module then calls for a four byte Password to be 
entered from the keyboard. Only after L0G.COM verifies that the 
Password entered corresponds to the Password in the ACCT.SYS file 
for the particular USER ID used will the operator be considered 
"logged-in" and be able to use the system. A corresponding 
"Privilege Level," previously assigned in the ACCT.SYS file, is 
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also activated at this time. A detailed discussion of the 
Password, Privilege Level and USER ID functions now follows. 

1. User Identification (USER ID) 



CP/M contains a seldom used feature called "USER". Origi- 
nally implemented in CP/M to provide upward file compati- 
bility with MP/M, the "USER" facility essentially tacks onto 
the directory entry for a file a "user number" between and 
15. The directory entry, and hence the file, are only 
visible and utilizable when the operator has invoked the 
"USER" number attached to the file. The default "USER" 
number, when CP/M is first loaded, is USER [0]. Hence, most 
of your files will be in USER [0] area unless you are cur- 
rently making use of this facility. The ULC-OPSnet "USER 
ID" corresponds to the CP/M "USER" number. Before going 
further, please take a moment to familiarize yourself with 
the CP/M USER facility by performing the following exercise 
with the STAT.COM file. Start by cold booting your system 
with the system diskettes prepared in Chapter 3. Do not load 
ULCOPS for this exercise. 

+ + 

A>USER 1<RET> 

A>DIR<RET> 

NO FILE (file names will appear on the KAYPRO 10) 

A> PIP STAT . COM=STAT . COM[G0] <RET> 

PIP? 

A>USER 0<RET> 

A>DIR<RET> 

A: PIP COM : STAT COM : (etc.) 

A> 
+ + 

In this case we told CP/M to invoke USER [1], and to display 
the directory. CP/M told us that the directory was empty 
(NO FILE), even though we know it is not empty for USER [0]. 
We then attempted to "PIP" the STAT.COM file to USER [1] 
area from USER [0] area (hence the CG0], meaning "get from 
USER [0]"). The system could not find PIP.COM, however, 
because "PIP" was only in USER [0] area. We then changed 
back to USER [0] and displayed the directory to verify that 
the files were in fact on the diskette. 

ULC-OPSnet assigns the CP/M active "USER" byte during the 
LOGIN process. You will recall from Chapter 3 that you were 
able to LOGIN as USER ID [0] and USER ID [1]. Eight addi- 
tional USER ID numbers are available at each workstation [2- 
9] permitting up to ten different "classes" of users for 
each station on the network. Unlike CP/M, ULC-OPSnet ties 
each of the USER ID's to a Privilege level, which in turn, 
determines each operator's "privilege" to access files from 
a different USER ID. Also unlike CP/M, ULC-OPSnet permits 
"sharable" .COM and .OV? files in USER ID [0] to be executed 
by operators with other USER ID's. With this feature, it is 
not necessary to reproduce mutiple copies of .COM programs 
and their associated overlays. Before leaving the section 
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on USER ID, try the previous example under ULC-OPSnet to 
make certain that you understand the concept. 



A>ULCOPS<RET> 

ULC-OPSnet vl . 7x Workstation - Node 
Opsnet by Aquinas, Inc. Copyright (c) 1983 

<A0>LOGIN 1<RET> 

Password: DEMO (note that **** will display) 

Logged-in on ULCOPS-net vl . 7x Workstation - Node 

Opsnet by Aquinas, Inc. Copyright (c) 1983 

[1] User: USER 1001 

<A1>DIR<RET> 

? Directory for disk a: user 1 is empty 



< Al > PIP STAT . COM=STAT . COM[G0] <RET> 

?Not privleged 

<A1>USER 0<RET> 

?Not privleged 

<A1> 



In the above example, you logged-in as USER ID [1], and 
asked for a directory, which was empty. As in the previous 
CP/M example, you attempted to "PIP" the STAT.COM file from 
USER [0] to your USER [1] area. Unlike the CP/M example, 
ULC-OPSnet found the PIP.COM file because it automatically 
searched shared .COM files in USER [0] area. It did not, 
however, complete the command because you were not "Privi- 
leged". The system would not permit you to change to USER 
[0] either, again because of "Privilege Level". This brings 
us to the next important aspect of system access controls, 
Password and Privilege Level. 



NOTE: 



Password 



Ideas and concepts on setting up applications with 
different "classes of users" will be discussed in 
a later chapter. 



The Password is a unique set of four character literals 
assigned by the network manager at installation time to each 
USER ID at each station in the network. ULC-OPSnet is 
shipped with two Passwords in the ACCT.SYS file to facili- 
tate installation. You have already used both of these 
passwords in Chapter 3; viz., 1111 for USER ID [0] and DEMO 
for USER ID [1]. The characters comprising the Password may 
be any ASCII characters except for a "$" or terminators such 
as a line feed or carriage return. Upper or lower case is 
significant; thus "DeMo" is a different Password than 
"DEMO". Additionally, a user name is also assigned to the 
USER ID and Password. The user name is only to facilitate 
the Gatekeeper in associating a name with a node number and 
USER ID. It is for display purposes only, and has no 
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function in maintaining security. You will note that the 
Password must be entered absolutely as it is stored. If 
not, ULC-OPSnet will force the operator to initiate a new 
LOGIN sequence. Try this: 



A>ULCOPS<RET> 

ULC-OPSnet vl.7x Workstation - Node 
Opsnet by Aquinas, Inc. Copyright (c) 1983 

<A0>LOGIN 1<RET> 

Password: demo (note that only **** will display) 

?Invalid password - Please LOGin again. 

<A0> LOGIN 1<RET> 

Password: DEMOO (note that only ***** will display) 

?Invalid password - Please LOGin again. 

<A0>LOGIN 1<RET> 

Password: DEMO (note that only **** will display) 

Logged-in on ULCOPS-net v.l.7x Workstation - Node 

Opsnet by Aquinas, Inc. Copyright (c) 1983 

[1] User: USER 1001 

<A1> 



Notice that as you typed in the characters for the password 
an asterisk (*) was displayed instead of the character you 
typed. This feature prohibits an unauthorized person from 
viewing the password as it is being entered. 

In the above example, neither the incorrect Password nor the 
correct Password with too many characters were acceptable to 
the system. Later in this Chapter you will see how the 
REACT.COM program is used to set and change Passwords. 

3. Privilege Levels 

In addition to a Password, each USER ID at each station also 
has an associated Privilege Level which governs access to 
files and system resources. The four possible Privilege 
Level codes, together with a description of each, are set 
forth below: 

CODE 1 - Local access - may LOGIN and access all local 
files (that is files resident on disk at the local 
station) only in the user area corresponding to the 
USER ID at LOGIN. Also, may execute local .COM and 
.OV? files located on the System disk (Disk A:) in USER 
ID [0] area. May execute SEND, SPOOL, QUEUE, and MAIL . 
May not change USER ID, and may not use files located 
on other stations in the network. 

CODE 3 - Local access, with ability to change USER ID - 
may LOGIN and perform functions identical to a Privi- 
lege Level 1 operator. May also change USER ID by 
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executing the USER command. May not use files located 
on other stations in the network. 

CODE 5 - Remote access - may LOGIN and perform func- 
tions identical to a Privilege Level 1 operator. May 
also use files located on other stations in the net- 
work. May not change USER ID. 

CODE 7 - Remote access, fully privileged - May LOGIN 
and perform all functions identical to a Privilege 
Level 3 and Level 5 user combined. May change remote 
Private files to Sharable, and may Lock and Unlock 
files. May change USER ID. May execute the REACT 
command only if the operator was able to LOGIN with a 
USER ID L0j. An operator with a Privilege Level of 
"7", but with a LOGIN USER ID other than [0], may 
change to USER [0] area and manipulate files in USER 
[0] area, but may not run the REACT.COM program or 
access the ACCT.SYS file. Thus, if the network manager 
is the only operator in an installation with a Password 
permitting LOGIN as USER ID [03 at all stations in the 
network, a Privilege Level of "7" may be assigned to 
other operators in the network without fear of unau- 
thorized access to Passwords or the ability to alter 
them. 



THE REACT.COM PROGRAM - CHANGING PASSWORDS AND PRIVILEGE LEVELS 

The REACT.COM program is a ULC-OPSnet utility program used 
to establish and change Passwords and Privilege Levels for each 
of the possible USER ID's at each station. REACT.COM may be run 
from any of the nodes in the network locally and may also be 
executed from the Gatekeeper (Node G) to act on Passwords and 
Privilege Levels at any other node in the network. We will 
practice using the REACT.COM program from the Gatekeeper. Do not 
attempt to make final assignments of Passwords, Privilege Levels, 
and USER ID's until you have completed the entire manual and have 
organized your approach to applications and operations structure. 
Try the following from the station in the network with the 
Gatekeeper software . 



+- 



A>ULCOPSG<RET> 

ULC-OPSnet vl . 7x Gatekeeper - Node 
Opsnet by Aquinas, Inc. Copyright (c) 1983 

<A0>LOGIN 0<RET> 

Password: 1111 

Logged-in on ULCOPS-net vl.7x Gatekeeper - Node 

Opsnet by Aquinas, Inc. Copyright (c) 1983 

[0] User: MANAGER 7000 

<A0>INET XER0X<RET> 

Gatekeeper running.... 
<A0> REACT <RET> 



4-6 



The screen of the CRT will blank, and then the following screen 
will appear: 

NOTE: Even though the Gatekeeper is always designated as 
station ID "G" (Node G) the screen will display a 
Station since "0" is always used to refer to the 
local station. The designation "0" will also be 
used by many other commands in ULC-OPSnet to refer 
to the local station. 



User 


1 
2 

3 

4 
5 
6 
7 
8 
9 



React vl.3 
Station Local 
Paswrd Name Privs 



1111 MANAGER 
DEMO USER 



XPRVS 

00 
00 



************************** 

* (1) - Add/modify entry * 

* (2) - Delete entry * 

* (3) - Change Station * 

* (4) - Save Changes * 

* (5) - Exit / No changes* 
************************** 



Enter selection: 



Note the first two entries (for Users [0] and [1]) are already in 
the table. These entries have been supplied so that the network 
may be utilized before any station operator controls have been 
implemented. These particular entries permitted the LOGIN of the 
Gatekeeper and the Workstations as (USER ID [0], MANAGER) and 
(User ID [1], USER) onto the network earlier for testing pur- 
poses. These entries may now be deleted or changed in any way 
desired. The following material describes the operation of each 
of the 5 selections in the REACT.COM menu for the Gatekeeper. 

1. Add/ modify entry 

User ID? - Press RETURN to return to main menu. An 
invalid USER ID causes "?Invalid selection" to appear. 

Password? - The current password is displayed and the 
cursor is positioned on the first position. Up to 4 
characters may be changed. When the RETURN key is 
pressed or when all entries are made, the field is 
stored as it appears on the screen. If an attempt is 
made to enter more than 4 characters, the next field, 
"User name", will be displayed. 
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Name? - The current name is displayed and the cursor is 
positioned on the first position. Up to 9 characters 
may be changed. When the RETURN key is pressed, or 
when the 9th character has been entered, the field is 
stored as it appears on the screen. If an attempt is 
made to enter more than 9 characters, the next field 
"privileged" appears. 

Privilege? - The current privilege level is displayed 
with the cursor on it. If the RETURN key is pressed, 
the original privilege level is stored. If an attempt 
is made to enter more than one character or an invalid 
character, "privileges?" appears and the operator is 
reprompted. 

2 . Delete entry 

User ID? - Pressing RETURN causes a return to main 
menu. An invalid USER ID (either an entry other than 0- 
9 or a 0-9 where there is no information in the 
ACCT.SYS file) causes "?Invalid User ID" to appear and 
reprompts the operator. A valid entry causes hyphens to 
replace the data in all fields. After a valid entry, a 
new table is displayed with the appropriate USER ID 
information deleted (the deletion is not yet saved) and 
the menu reappears. 

3. Change Stations 

Station ID? - Pressing RETURN causes a return to main 
menu. A valid entry causes a table for the station 
selected to appear together with the menu. Changes to a 
remote workstation's ACCT.SYS file may now be made from 
the Gatekeeper as described above. Note: Previous 
changes must be saved before changing stations or all 
changes will be lost. See 4 and 5 below. An Invalid 
Station ID, or a Valid Station ID where the station 
accessed is properly "INET"ed, will cause the "Node x 
Busy or unavailable - Retry? (Y/N)" message and prompt 
to display. 

4. Save Changes 

If 4 is entered, all changes are permanently made and 
operator is returned to REACT menu. The previous ACCT 
.SYS file is saved as ACCT.BAK and the new information 
is saved in ACCT.SYS. 

5 . Exit - No Changes 

If 5 is entered, no changes are made and operator is 
returned to system prompt. 

The REACT program may also be run locally at any one of the 
Workstations, however, only information pertinent to that station 
may be changed. Technically, all information pertaining to the 
station operator controls is contained in a file called ACCT.SYS. 
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All ACCT.SYS files on the network may be accessed by the Gate- 
keeper. Only the ACCT.SYS file related to a given workstation may 
be accessed by that workstation. The following material describes 
how REACT functions when run from a non-Gatekeeper workstation. 

1. Menu selections 1, 2, 4 and 5 have the same meaning and 
function in a like manner as if REACT were run from a 
Gatekeeper. 

2. Selection 3 in menu still reads "Change station". If a 
3 is entered from a local station menu, the error 
message "?May not use this function unless a Gate- 
keeper" appears, and the main menu reappears after the 
5-10 second wait. 

Figure 4-1 is a detailed table outlining the various 
functions and commands available to each class of operator, i.e., 
each combination of Privilege Level and USER ID. It will be 
useful for you to review this table before you install all of the 
ACCT .SYS files in your network. It will also be useful for you 
to read the remainder of the User's Guide for an understanding of 
all of the ULC-OPSnet commands and system functions before estab- 
lishing operator Privilege Levels. If you permit Workstation 
operators to LOGIN as USER ID [0] with a Privilege Level 7 , you 
may want to ERAse the REACT.COM file from the diskettes to pro- 
hibit unauthorized changing of Passwords and Privilege Levels. 

FILE SECURITY 

A standard CP/M file may be stored with two kinds of "file 
attributes"; viz., whether or not the file name is to be viewable 
with the DIRectory command and whether or not the file may be 
erased or altered in any manner. These file attributes are in- 
voked with the use of the STAT.COM utility. Since the STAT.COM 
utility may be used by anyone, it is necessary to add additional 
file attributes in the network environment to guarantee a secure 
file system. ULC-OPSnet implements two additional file attri- 
butes to assist in creating a more secure networked file system. 
In addition, ULC-OPSnet also recognizes the standard CP/M file 
attributes of Read/Write or Read Only and Directory or System. 
The file control attributes available under ULC-OPSnet are as 
follows: 

1 * Read Only or Read/Write 

A read only file may not be modified or updated by 
anyone on the system. It is analogous to having the 
write protect notch covered on an 5-1/4" diskette. 

A read/write file may be modified or updated by anyone 
who is able to access the file. It is analogous to 
having the write protect notch uncovered on an 5-1/4" 
diskette. 
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2. Directory or System 

A directory file is a file whose name will always 
appear when a directory of files on a drive is taken. 

A system file is a file whose name will only appear on 
a directory when requested by a user with Privilege 
Level "7". 

3. Locked or Unlocked 

A locked file is automatically unavailable to other 
operators once it is opened and remains unavailable 
until unlocked. A locked file is automatically unlocked 
when it is closed. 

An unlocked file is available simultaneously to all 
operators with appropriate USER ID's or privileges. Any 
operator on any station may update a sharable 
read/write file which is unlocked. The contents of the 
file at any given time will reflect the last "saved" 
version. 

Note: Record lockout is automatic. When a record from 
an open file is accessed, it becomes unavailable 
to any other operator until operations on that 
record cease. 

4. Private or Sharable 

A private file may not be accessed from a remote sta- 
tion. A user with Privilege Level "7" may, however, 
make a remote private file sharable. 

A sharable file is available to all operators with 
appropriate USER ID's. 

In order to place the file attribute controls on a specific 
file, the PROTECT command is used. PROTECT is an internal ULC- 
OPSnet command that performs functions similar to those performed 
by the STAT.COM utility. The general format of this command is: 

+ + 

: <A0> PROTECT <device>: <filename> < attribute >< RET > : 

+ + 

The attribute refers to the four pairs of controls discussed 
above. Only one element of each pair may be entered at one time: 

CONTROL DESIRED TYPE FOR THE ATTRIBUTE 

1 . Read Only or Read/Write RO or RW 

2. Directory or System DIR or SYS 

3. Locked or Unlocked LOCK or UNLOCK 

4. Private or Sharable PRIV or SHAR 

For example, if you wish to put controls on a file called 
MYFILE.DOC on disk B:, such that it is: 
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Read Only, System, Locked, and Private, 
then perform the following operations: 



<A0>PROTECT B:MYFILE.DOC RO<RET> 

File(s) protect to Read/Only for disk B: user 
MYFILE .DOC 

<A0> PROTECT B: MYFILE. DOC SYS<RET> 

File(s) protect to System for disk B: user 0: 
MYFILE .DOC 

<A0> PROTECT B z MYFILE. DOC LOCK < RET > 

File(s) protect to Locked for disk B: user 0: 
MYFILE .DOC 

<A0> PROTECT B: MYFILE. DOC PRKRET> 

File(s) protect to Private for disk B: user 0: 

MYFILE .DOC 

<A0> 



OTHER RECOMMENDED SECURITY MEASURES 

The ACCT.SYS and REACT.COM files are shipped as: directory, 
read/write, shared, and unlocked . This is necessary to permit 
PIP.COM to copy these files from the master release diskette to 
the operational diskette or hard disk. PIP.COM will not copy 
files that are stored as system files. After copying the master 
release diskette, put it away. When using REACT.COM to change the 
ACCT.SYS file, REACT.COM will automatically store ACCT.SYS as: 
system, locked, private, and read/ w rite and create an ACCT.BAK 
file. Erase the ACCT.BAK file when changes are complete. For 
further protection, erase the REACT.COM file on all Workstation 
diskettes . 

It is recommended that no person other than those respon- 
sible for managing the network processing activities have access 
to Logging-in as USER [0] with a privilege level of "7". With 
this precaution, no unauthorized personnel may run the REACT.COM 
program at the Gatekeeper or workstations. It is also recommen- 
ded that a Privilege Level of "7" or "3" be assigned cautiously. 
These Privilege Levels permit changing USER ID, and thus allow 
the operator to erase or alter files in other USER areas. 

After the network is installed and operating satisfactorily, 
take appropriate measures to insure that the original diskettes 
(both Gatekeeper and Workstation versions) supplied in the User 
Guides are not available to unauthorized persons. 

PRE-DETERMINED, AUTOMATIC INITIALIZATION 

One of the features of ULC-OPSnet is a provision for auto- 
matic execution of programs at LOGIN time. This feature may also 
be used as a security measure. When the LOGIN command has been 
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executed and the Password supplied, ULC-OPSnet automatically 
searches the A: disk in the Logged-in USER area for a file named 
INITIA.INI. If no INITIA.INI file (on the A: disk) is found, the 
system returns the normal "<A0>" prompt. If an INITIA.INI file is 
found, the entries in this file are executed as commands. It is 
up to the user to supply a sequence of commands he wishes to be 
executed at LOGIN time. For example, suppose the network manager 
wanted Workstation (Node) #1 to automatically check the mail box, 
come to the "NET READY" status, and execute WordStar*(c) (WS.COM) 
each time USER [3] logs in. Further, since USER [3] is new and 
just learning word processing, the network manager wants the 
operator only to have access to WordStar, and LOGOUT when fin- 
ished. All of this can be accomplished by the creation of an 
INITIA.INI file for this user as follows (the example assumes the 
use of WordStar to create the INITIA.INI file, though any screen 
editor will suffice): 



<A0>USER 3<RET> 
<A3>WS 



1. 



Use the "N", or non-document option in WordStar by 
typing an N when the "NO FILE MENU" appears. 



2. Once into WordStar, supply the following commands: 

+ + 

MAIL<RET> 

INET KAYPRO 1 <RET> 

WS<RET> 

LOGOUT<RET> 

~KX 

< A3 > USER 0<RET> 

<A0> 

+ + 

Now, each time USER [3] executes a LOGIN on Station #1, the com- 
mands contained in the INITIA.INI file will be executed just 
after the RETURN key is pressed following the password. In the 
above example, the workstation will be identified as a KAYPRO, 
Station #1. If there is any mail, it will be displayed. If not, 
the message: 

Mail box is empty 

will appear (see Chapter 6). The network will be initialized (see 
Chapter 5) and the prompt: 

NET READY 

(network initialization message) 

will appear. WordStar will then load. When the operator leaves 
WordStar, he will automatically be Logged-out of ULC-OPSnet. 



11 WordStar Tii a registered trademark of MicroPro International 
Corporation . 
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If there are plans for multiple operators to use each workstation 
at different times, each with his own Password, USER ID, and 
Privilege Level, a different INITIA.INI file can be created for 
each operator simply by invoking the "USER" command prior to 
creating and storing the INITIA.INI file. 

AUTOMATIC LOAD OF ULC-OPSnet 

Another consideration in implementing security measures is 
to limit access to the standard CP/M operating system. Since 
there is no built-in password facility or other file security 
measure in CP/M, anyone with access to a system need only "boot" 
the system and use the CP/M "USER" command to be able to view and 
"PIP" any of the files locally. While the password facility in 
ULC-OPSnet prohibits unauthorized access to files over the net- 
work, the only method of limiting unauthorized access to files 
resident on a local workstation is to force the users of the 
workstation to use the ULC-OPSnet system and go through the LOGIN 
and Password routine. Once ULCOPS is loaded, a proper LOGIN and 
Password verification must occur before the user has access to 
any system facilities. The next section deals with automatically 
loading ULC-OPSnet on the variety of microprocessor for which you 
may have purchased this system. 

HOW TO AUTO-LOAD ULC-OPSnet ON THE KAYPRO Model 10 

The CP/M system supplied with the KAYPRO Model 10 has two 
utilities called "PUTSYS.COM" and "GENFLPY.COM". These utiliti- 
ties are used to record the CP/M operating system on the system 
tracks of the hard disk and floppy diskettes respectively. Your 
ULC-OPSnet release diskettes contain a copy of the "PUTSYS.COM" 
utility called either "PUTWULC.COM" or "PUTGULC.COM". These 
utility programs are versions of the KAYPRO "PUTSYS.COM" utility 
with one addition: each utility on your ULC-OPSnet release disk- 
ette records a command line that is executed immediately after 
the CP/M operating system is loaded. The other specialized ver- 
sion of a KAYPRO utility on your ULC-OPSnet release diskette is 
called either "GENWFP10.COM" or "GENGFP10.COM", each of which is 
the version of "GENFLPY.COM" that records a command line on the 
system tracks of diskettes to be used as "bootable" diskettes on 
the Model 10. If your ULC-OPSnet release diskette is a Gate- 
keeper software diskette, the command line executed (either from 
the bootable floppy or from the hard disk on a cold boot) is 
"ULCOPSG"; if your diskette is a Workstation software diskette, 
the command line executed is "ULCOPS". 



PROCEDURE FOR KAYPRO Model 10 HARD DISK 

Use the following instructions to force ULC-OPSnet to load 
after every cold boot. Once you have established a CP/M system 
track configured to auto- load ULC-OPSnet, a proper LOGIN sequence 
will be required every time the system is turned on or the "RE- 
SET" button is pushed. Thus, no-one will be able to operate the 
system without access to a valid Password. 
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Turn on the computer or press the RESET button if the compu- 
ter is already on. (The locations of the ON/OFF switch and 
RESET button are shown in your KAYPRO manual). 
The screen will display the following: 



KAYPRO 10 CP/M Version 2 . 2x 
A0> 



Make certain that you have performed all of the steps in the 
ULC-OPSnet installation process as documented in Chapter 3. 
In addition to the standard ULC-OPSnet files on the A: 
partition of the hard disk, you should also have "PUTG- 
ULC.COM" and "GENGFP10.COM" (if the station is to be a 
Gatekeeper) or "PUTWULC.COM" and "GENWFP10.COM" (if the 
station is to be a Workstation). 

Perform the following (if a Gatekeeper): 

+ + 

: A0 > PUTGULC<RET> 

PUTSYS VER 1.x 

:A0> 

+ + 

-or- 

Perform the following (if a Workstation): 

+ _ + 

: A0 > PUTWOI.C<RET> 

PUTSYS VER 1.x 

!A0> 

+ + 

Push the RESET button. The following should now appear: 

+ + 

: KAYPRO 10 CP/M Version 2.2x 

ULC-OPSnet vl.70x (Workstn. or Gatekpr.), Node 
OPSnet by Aquinas Inc., Copyright (c) 1983 

<A0> 

+ + 

You will now find that ULC-OPSnet is loaded every time the 
KAYPRO 10 is "RESET". This will require a proper LOGIN and 
Password to be used before access is gained to the system. 
Now go ahead and perform a normal LOGIN as USER [0]. 
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6. To make certain that "PUTSYS.COM" f "N0MENU.COM", and "GEN- 
FLPY.COM" are not misused, backup each of these files on 
your ULC-OPSnet release diskette and erase them from the 
hard disk. "PUTSYS.COM" and "N0MENU.COM" both record the 
CP/M operating system on the system tracks of the hard disk, 
but without the command line that would otherwise force the 
loading of ULC-OPSnet and the LOGIN procedure. "GENFLPY.- 
COM" permits booting the KAYPRO 10 from the floppy disk 
drive in standard CP/M, and thus the viewing of files on the 
hard disk. If an unauthorized operator had access to these 
programs, he would be able to read and alter files on the 
hard disk. The procedure is as follows: 

a. Place the ULC-OPSnet release diskette in the floppy 
disk drive. 

b. Perform the following operations. 



<A0>GENFLPY<RET> {This procedure 

{"SYSGEN"s a copy 

SOURCE SKIP?<RET> {of standard CP/M 

FUNCTION COMPLETE {on the diskette 

DESTINATION SKIP?C {in case you need to 

FUNCTION COMPLETE {boot w/o ULC-OPSnet 

DESTINATION SKIP?<RET> 

<A0>PIP Cs=A:PUTSYS.COM[VO]<RET> 

<A0>ERA A:PUTSYS.COM<RET> 

<A0>PIP Cs=AsNOMENU.COM[VO]<RET> 

<A0>ERA A:NOMENU.COM<RET> 

<A0>PIP C:=A:GENFLPY.COM[VO]<RET> 

< A0 > ERA A : GENFLPY . COM[ V03 < RET> 

<A0> 



c. Now put the ULC-OPSnet release diskette in a safe or 
other suitable storage place. 

PROCEDURE FOR KAYPRO Model 10 BOOTABLE FLOPPY DISKETTES 

As a further precaution against unauthorized access to 
files, all floppy diskettes you intend to be bootable on a KAYPRO 
10 should be "SYSGEN"ed with either "GENWFP10.COM" or "GEN- 
GFP10.COM", and should have (at a minimum) a copy of either 
"ULC0PS.COM" or "ULC0PSG.COM" on the diskette in USER [0]. If 
this procedure is followed, then all floppy diskettes booted on a 
KAYPRO 10, whether for transporting data or backup, will load 
ULC-OPSnet when booted, and will not permit access to the data 
files on the hard disk without satisfying the standard LOGIN 
sequence. Perform the following on each floppy you intend to be 
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bootable on a KAYPRO 10 (the example assumes a Gatekeeper; sub- 
stitute "GENWPP10" and "ULC0PS.COM" for a Workstation): 

a. Placea formatted diskette in thefloppy disk drive. 

b. Perform the following operations individually on each 
diskette: 



+ + 

: <A0>GENGPP10<RET> {This procedure } 
: {"SYSGEN"s a copy of} 

: SOURCE SKIP?<RET> {CP/M with the ULC- } 

•.FUNCTION COMPLETE.... {OPSG command line } 

DESTINATION SKIPPC {causing ULCOPSG.COM} 

: FUNCTION COMPLETE {to load on each boot} 

DESTINATION SKIP?<RET> 

+ 




c. You need not have any file on the diskette other than 
"ULC0PSG.COM" (or, "ULC0PS.COM" , if you used "GEN- 
WFP10.COM" in the previous example) in order to pre- 
serve the integrity of the security system. 

HOW TO AUTO-LOAD ULC-OPSnet ON THE KAYPRO Models 2 and 4 

The procedure for causing the "ULCOPS" or "ULCOPSG" command 
line to be recorded on the system tracks of a diskette to be 
bootable in a KAYPRO Model 2, 4, or 4E is to use the C0PY.COM 
utility supplied by KAYPRO. Remember that the C0PY.COM utility 
was renamed to F0RMAT.COM as part of the installation procedure. 
This was necessary as ULC-OPSnet recognizes COPY as an imbedded 
command in the system. When executing the FORMAT (KAYPRO COPY.- 
COM) program, after a diskette has been formatted and copied, you 
will be prompted by the system as to whether or not you wish to 
record a command line upon cold boot. The command line to cause 
to be copied is ULCOPSG if this is to be a Gatekeeper diskette or 
ULCOPS if it is to be a Workstation diskette. REMEMBER: If you 
do not wish the floppy diskette to be utilized by other than an 
authorized user, either the ULCOPSG.COM or the ULCOPS.COM program 
must be on the diskette in addition to recording the appropriate 
command line on cold boot. 
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CHAPTER 5 
ASSIGNMENT OF DEVICES 



One of the outstanding features of networking microcomputers 
under ULC-OPSnet is the ability to assign physically remote 
devices (such as disk drives) to a local workstation. For exam- 
ple, Workstation #1 may have two floppy disk drives (A: and B:) 
attached to it physically. Logically Workstation #1 could have 16 
disk drives (A: through P: with M:, 0:, and P: reserved). There- 
fore, Workstation #1 may assign as its C: disk drive, for 
example, the A: disk drive of Workstation #2. After the assign- 
ment, Workstation #1 may perform operations on its C: disk (the 
A: disk of Workstation 2) as if it were physically attached to 
Workstation #1. 

Although files may be physically transferred over the net- 
work from workstation to workstation with ease, in most cases 
such a transfer is not necessary. A local workstation may execute 
programs located on a remote workstation over the network without 
physically transferring the remote files to the local 
workstation . 



THE "WHERE" COMMAND (OBTAINING A TABLE OF DEVICE ASSIGNMENTS) 

To obtain a table of device assignments in effect for your 
local workstation, simply type at the system prompt: 

+ + 

<A0 > WHERE <RET> 



: Log: 


Phy: 


Location 


: A: 


A: 


Local 


: B: 


B: 


Local 


: LST: 


LPT: 


Local 


: PUN: 


TTY: 


Local 


: RDR: 


TTY: 


Local 


: CON: 


CRT: 


Local 


: <A0> 







+ 

This is the default device assignment table immediately after 
LOGIN. The table shows that all devices are local and: 

The logical drives A: and B: are the physical drives A: 

and B:. 

The list device (LST) is a printer (LPT:). 

The punch device (PUN) is a teletype (TTY:). 

The reader device (RDR) is a teletype (TTY:). 

The console device (CON) is a terminal (CRT: ) . 

Another form of the WHERE command is: 

WHERE <Dev>:<RET> 
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which will display the location of a specific device on the 
network . 

The WHERE command may be invoked at any time after a system 
prompt . 

THE "ASSIGN" COMMAND (CHANGING THE TABLE OF LOGICAL DRIVE 
ASSIGNMENTS) 

To make changes in the table of logical disk device 
assignments, the ASSIGN command is used. The general format is: 

+ . + 

: ASSIGN <logical disk> s =<physical disk>: < station ID><RET> : 

+ + 

For example, you are at Workstation #1 and you wish to operate on 
files which are resident on the A: drive of Workstation #2 and 
the B: drive of Workstation #3. At the system prompt, type: 

+ + 

<A0> ASSIGN C:=A:2<RET> 
Device C: assigned 

<A0>ASSIGN D:=B:3<RET> 

Device D: assigned 

<A0>WHERE<RET> 



Log: 


Phy: 


Location 


A: 


A: 


Local 


B: 


B: 


Local 


C: 


A: 


Node 2 


D: 


B: 


Node 3 


LST: 


LPT: 


Local 


PUN: 


TTY: 


Local 


RDR: 


TTY: 


Local 


CON: 


CRT: 


Local 



<A0> 

+ + 



Now the logical disk C: at Workstation #1 is the physical disk A: 
at Workstation #2 and the logical disk D: at Workstation #1 is 
the physical disk B: at Workstation #3. You now have four sepa- 
rate disk drives containing their respective files available to 
you for processing. 

It is also possible to assign the local logical disks A: and 
B as other physical drives on the network. Caution ; even though 
the currently logged disk may be B: (or some other disk) the 
system disk always resides in drive A:. Therefore, if the logi- 
cal disk A: must be assigned elsewhere, it should only be 
assigned as the physical disk A: at some other workstation. 

A disk drive may also be "deassigned" using the ASSIGN 
command. If any local logical disk C: through P: had been pre- 
viously assigned as a physical disk on some other workstation it 
may be deassigned by typing: 
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+ + 

: <A0> ASSIGN C: <RET> : 

: Device assigned : 

: <A0> : 

+ + 

The net effect of (Reassigning any disk C: through P: is that 
there will now be no entry for that disk in the table of 
assignments. 

If local logical disk A: or B: had been previously assigned 
as the physical disk at some other workstation, it may be deas- 
signed by typing: 

+ + 

<A0> ASSIGN B:<RET> 
Device B: assigned 

<A0>WHERE<RET> 



Log: 


Phy: 


Location 


A: 


A: 


Local 


D: 


B: 


Node 3 


LST: 


LPT: 


Local 


PUN: 


TTY: 


Local 


RDR: 


TTY: 


Local 


CON: 


CRT: 


Local 



<A0> 
+ + 

The net effect of deassigning any disk A or B is that the entry 
for the deassigned disk will be deleted. 

Note: The A: (System Disk) should never be deassigned. 

THE "SPOOL" COMMAND (ASSIGNING A PRINTER TO A WORKSTATION) 

Just as the ASSIGN command is used to make assignments of 
disk drives, the SPOOL command is used to assign a printer to a 
particular workstation. The general format of the command is: 



<A0> SPOOL <station ID><RET> 
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If you wish to use a printer at Workstation #4, type: 

+ + 

<A0> SPOOL 4<RET> 

Spooler is remote - Node 4. 

<A0>WHERE<RET> 



Log: 


Phy: 


Location 


A: 


A: 


Local 


B: 


B: 


Local 


LSTj 


LPT: 


Node 4 s 


PUN: 


TTY: 


Local 


RDR 


TTY: 


Local 


CON 


: CRT: 


Local 



spooler 



<A0> 

+ + 

The table now shows that all printing operations from your local 
workstation will be performed on the printer located at Station 
4. 

If you don't know where your spooler is currently assigned, 
type: 

+ + 

: <A0>SPOOL<RET> : 

: Spooler is remote - Node 4 : 

: <A0> : 

+ . + 

If a printer is attached to your local workstation and you 
wish to use it and the table shows the LST device at another 
location, type: 

+ + 

: <A0> SPOOL 0<RET> : 

: Spooler is local : 

: <A0> : 

+ . + 

Now the printer is assigned locally. 

GETTING INFORMATION ABOUT FILES ON THE NETWORK 

Many times you will not know which diskettes are resident on 
which drives at which workstations. To determine which files are 
resident on your local drive B:, type: 



<A0>DIR B:<RET> 
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A directory of disk B: will be displayed. To obtain a directory 
of the currently logged (default disk), type: 



<A0>DIR<RET> 



A directory of disk A: (the logged disk) will now be displayed. 
The DIR command under ULC-OPSnet functions similarly to the DIR 
command under CP/M except as noted in the Technical Manual. One 
such difference is the use of the "/W" switch. Using the /w 
switch in a DIR command under ULC-OPSnet provides detailed infor- 
mation about each filename such as: 

Ext (file type extension) 

Ace (access status) 

Recs (number of records in file) 

Size (file size in K-bytes) 

Access Notes (is file PRIVATE, LOCKED, etc.) 

Total number of files and amount of storage used 

in the device's user area. 



A summary of total size and number of files is also displayed 
when using the /w switch. For example, to take a directory of 
disk A using the /W switch, type: 



: <A0>DIR A:/W<RET> 

+ 



The directory of disk A will now be displayed under the following 
columnar headings: 



Directory for disk A: User 
Filename Ext Ace Recs Size Access Notes 



The files will be displayed one file per line. The scrolling of 
the screen may be stopped at any time by depressing the "CTRL" 
and "S" keys (CTRL-S) simultaneously. The display may be restar- 
ted by a CTRL-S. The display may be aborted by depressing CTRL-C. 

In a similar fashion directories may be taken from remote 
disks by first assigning that remote disk to your local worksta- 
tion and then taking a directory. For example, you are at 
Workstation #1 and wish to take a directory of the files which 
are resident on drive B: of Workstation #5: 



<A0>ASSIGN C:=Bs5<RET> 

Device C: assigned 
<A0>DIR C:/W<RET> 
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A directory of the B disk at Workstation #5 will now appear on 
the screen of Workstation #1 in the detailed format. 

The DIR command may also be used with an individual file 
name : 

+ + 

: <A0>DIR A:MYFILE.DOC/W <RET> : 

+ + 

The information relating to the file called MYFILE.DOC on disk A 
will be displayed in the detailed format. 

The DIR command may also be used to print the contents of 
the directory on a locally attached printer. This printing is 
done by using the /P switch as follows: 

+ + 

: <A0>DIR/P<RET> : 

+ + 

Selected directory entries may also be printed using the /P 
switch such as: 

+ + 

: <A0>DIR *.COM/P<RET> : 

+ + 

This entry will cause all .COM file names in the directory 
of the default disk to be printed. 

The /W and /P switches may also be used together, for 
example: 

+ + 

: <A0>DIR/WP<RET> : 

+ + 

will cause the detailed directory information on the default disk 
to be printed on the locally attached printer. 

You may also use the FIND.COM program to locate which logi- 
cal disks already assigned contain certain files. For example, if 
you wish to find out which drives contain WS*.* files: 

+ + 

: <A0>FIND WS*.*<RET> : 

+ + 



THE "LOCATE" COMMAND 

The search for files on the network could be quite time 
consuming if every disk drive is assigned locally one at a time 
and directories then taken. The LOCATE command is available to 
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speed up the file search by assigning your workstation the local 
disk drive assignments of a remote workstation. For example, you 
are at Workstation #1 and wish to have the disk device 
assignments of Workstation #5 at your workstation. The entry: 




provides that the local disk device assignments specified for 
Workstation #5 are now the assignments for Workstation #1 and 
directories may be taken as desired. The primary use of this 
command is to locate files on remote disks rapidly. If n users 
locate to remote stations, network traffic is increased in pro- 
portion to n. Therefore, due to station, network and disk conten- 
tions generated, this command should be used sparingly and a 
station once having found the desired files should locate back 
locally. To locate locally, type: 

+ + 

: <A0> LOCATE <RET> : 

: Located local : 

: <A0> : 

+-. + 

When the LOCATE command is used, only the disk drives A: and 
B: are displayed in the table. If you have located to a worksta- 
tion which is equipped with a hard disk, there may be files on 
C:. This additional drive will not be displayed in the table of a 
workstation which has just located to the hard disk workstation. 
To determine if any files are present on the hard disk Worksta- 
tion #5's physical drive C:, for example, the operator at the 
locating workstation enters: 

+ + 

: <A0>ASSIGN C:=C:5<RET> : 
: Device assigned : 

: <A0>DIR Cs5<RET> : 

+ + 

The directory of logical drive C: , the physical C: drive at node 
5, will now be displayed at the locating workstation. 

GETTING RAM INFORMATION AND PERFORMING A RESET 

As indicated previously the default disk may be changed from 
A: to any other valid disk device, providing the device has 
already been assigned, as follows: 
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+ + 

: <A0>H:<RET> : 

: <H0> : 

+ + 

Now the default (logged) disk will be disk H: . 

Other information commands are available: 

CORE Tests all RAM memory and displays how much 

RAM is available for the TPA. 

INITIALIZE Performs a BDOS disk reset function (similar 
to CP/M "warm boot") and displays the version 
of ULC-OPSnet in use together with the 
station ID. 

Note: This command (the short version is "I" 
<RET>) should be given each time a 
diskette is changed. 
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CHAPTER 6 
OTHER ULC-OPSnet OPERATIONS 



PRINTING A FILE 

Whenever a file is to be printed using the queue command and 
the spooler, the name of the file along with its physical device 
location is placed in the "spooler queue" which resides in 
background partition memory at the node previously designated as 
the spool node. There are four such queues so that the names of 
four separate files may reside at the spooler at one time. The 
spooler outputs each file on a first-in first-out basis to the 
printer. If the queues are full, the sending station operator 
will be so informed by a screen message: 

? The Queues are full. 

The sending operator may elect to use the spool command to set 
the spooler to some other workstation having a printer attached 
and reenter the QUEUE, or simply wait and attempt to print later. 

The command which initiates queued printing is: 

QUEUE < device > : <f ilename>/< switches ><RET> 

where <device> is the logical disk on which the file resides, 
<filename> refers to the name of the file to be printed and the 
switches are: 

A - Aborts file currently being printed. 

C# - Make # copies (# may be any number from 1 to 9) . 

E - Eject and send a form feed to the printing device. 

F - Special Forms: 

Executes QOFF at the spooler station. 

Sending operator must send a message to spooler 

console with Special Forms instructions. 

Assume a file called MYFILE.DOC resides on the B: disk of your 
Workstation #1. The spooler has been set remote to Workstation #4 
and the currently assigned list device (LST) at Workstation #4 is 
LPT:. The command: 

QUEUE BtMYFILE.DOC 

will cause the file MYFILE.DOC to be printed on the printer at 
Workstation #4. 

The currently assigned LST: device may be changed from LPT: 
to CRT:, UL1: or TTY: by: 

+ + 

: <A0>STAT LST:=CRT: <RET> : 

+ + 



6-1 



: <A0>QUEUE CRTs<RET> 

+ 



PRINTING FILES WITH SPECIAL WORD PROCESSING PRINTER DRIVERS 

Word processing applications like WordStar have provisions 
in their installation programs to generate "special" printer 
drivers. These special drivers generate the codes necessary to 
activate features like overstrike, bold print, underline, micro- 
justification, etc. Unfortunately, these special drivers usually 
can be accessed only by printing to a local printer through an 
application program with one of the drivers, and generally cannot 
be built into the CP/M LST: device portion of the BIOS. Since the 
complex program necessary to perform the ULC-OPSnet Queueing 
function is a separate system function, and cannot be built into 
WordStar or other specialized printing applications, a new proce- 
dure must be used to activate special word processing printing 
functions remotely. The following example assumes that the cus- 
tomer is using WordStar, but the procedure is similar for spooled 
printing from any other application program that provides spe- 
cialized printing drivers. 

NOTE: The print driver in WordStar and other applications 
must be configured for "any teletype-like printer," 
or "backspacing teletype-like printer," must address 
the printer as the CP/M LST: device, and must leave 
any communications protocol to the BIOS. The SPOOLER 
will not properly print a file with imbedded print 
drivers and protocols. 

1. Choose a temporary disk file name to which the document 
file will be printed. 

2. "ASSIGN" the LST: device to that file name; e.g. 



<A0> ASSign LST:=B:TEMP.PRN<RET> 

LST: Spooled to B:TEMP.PRN 



3. Bring up WordStar; e.g., type: 

+ + 

: <A0>WS<RET> : 

+ + 

Note: The standard WordStar "NO-FILE MENU" will appear. 

4 . Type : 



NAME OF FILE TO PRINT? 
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5 . Type : 



: <dev> : < f ilename> <RET> 

+ 



Note: WordStar will now ask you for some information; 
e.g. 

+ + 

: For default press RETURN for each question: : 
: DISK FILE OUTPUT (Y/N) : : 

+ . + 

Ignore this list of questions and simply depress the 
<ESC> key. 

WordStar will tell you that it is printing <dev>:<file- 
name> when, in reality, it is creating a disk output 
file of the document with all of the special printer 
control codes in a file called "TEMP.PRN". 

When WordStar has completed creating the required output 
files, they must now be closed. Since WordStar "thought" 
that the documents were actually being printed it does 
not know that a disk file must be closed. Closing the 
special document disk file is accomplished with the 
FINISH command. 

After exiting WordStar, type: 



<A0>FINISH<RET> 

LST: file closed as B:TEMP.PRN 
<A0> 



10. Now you are ready to Queue the printed file to whatever 
node you have previously defined as the node for your 
spooled output. 

1 1 . Type : 



<A0> Queue B : TEMP. PRN< RET > 

<A0> 



12, 



The spooler will now take over and Queue the print file 
to the printer at the node specified. The operator may 
continue with other processing. 

Two small Submit files, PRINTON.SUB and PRINTOFF.SUB, 
are supplied if you wish to print without leaving 
WordStar. These are accessed in WordStar by use of the R 
command as follows: 
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a. Omit steps 1 and 2 and after step 3, above, execute 
the R function in WordStar and type: 

+ + 

: Command? PSUB PRINTON : 

+ + 

b. Next perform steps 4, 5, and 6 above. 

c. WordStar will now have prepared a disk file named 
WS.PRN on the logged in disk. 

d. Next, execute the R function and type: 

+ + 

: Command? PSUB PRINTOFF : 

+ + 

e. Next, execute the R function and type: 

+ + 

: Command? QUEUE WS.PRN 

+ , + 



INTERSTATION MESSAGES 

In Chapter 3 you were introduced to the concept of sending 
messages over the ULCnet. The general format of the command is: 

+ + 

: SEND <station ID> <message> : 

+ + 

where station ID may be any currently logged in node ID (or the 
word "ALL") and the message may be any combination of up to 120 
ASCII characters. If an attempt is made to enter more than 120 
characters, the first 120 character message is sent upon the 
121st keystroke. The message will be displayed at the receiving 
station's screen. Note that the receiving station does not 
return to a system prompt after the message since the operator * 
may have been in the middle of processing when interrupted by the * 
message. After the message display, the operator will be free to i 
continue. If a system prompt is desired at the receiving station, J 
the operator simply enters a <RET>. 

Under ULC-OPSnet, all stations physically connected to the 
ULCnet with INET initialized will poll their network ports con- 
tinuously while the CPU is available. The receiving port detects 
incoming message, displays it on the screen and sends an acknowl- 
edgement back to the transmit station. If acknowledgement is not 
received within one second or less, depending on CPU clock 
frequency, a busy or unavailable message is displayed. 

If a station operator is executing an application and does 
not wish to be interrupted by incoming messages on the screen, a: 
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+ 

: <A0>TTY GAG<RET> 

: <A0> 

+ 



command may be issued. While this command is in effect, no mes- 
sages will be received unless the station is in the monitor mode, 
i.e., at <A0>. A "busy or unavailable" message will appear on the 
sender's screen if the message is not received. To remove the GAG 
command, enter: 



<A0>TTY NO GAG<RET> 

<A0> 



ELECTRONIC MAIL 

ULC-OPSnet supports transferring files with electronic mail. 
The general command format is: 

MAIL <NodeID><USER [ID]> <device>s <f ilenarae> 

For example, to mail a file to workstation #2 from another 
location the mailing operator would enter: 

+ + 

: <A0>MAIL 21 B:MYFILE.DOC<RET> : 

+ + 

This would cause the file MYFILE.DOC on the mailers* assigned 
B: disk to be transferred to the USER [1] mailbox at station 2. 
In the USER [1] mailbox at station 2, the file would be named 
MAIL0.MAL. If a second file were mailed into the same mailbox it 
would be named MAIL1.MAL. Up to nine files may be in any one 
mailbox at the same time. A valuable feature of ULC-OPSnet Elec- 
tronic Mail is that .COM files may be mailed. At the receiving 
station, if the operator renames the file it may then be 
executed. For example, PIP.COM could be mailed from station #1, 
USER [0] to station #2, USER [1] by: 

+ + 

: <A0>MAIL 21 PIP.COM<RET> : 

+ + 

Then, at station 2: 

+ + 

: <A1>REN PIP.COM=MAIL0.MAL<RET> : 

+ + 

The contents of the mailbox can be checked by the command: 

+ + 

: <A0>MAIL<RET> : 

+ + 
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If there is mail, the file names will be displayed. If no mail, 
then the message: 



Mailbox is empty 



will be displayed. 

The receiving station's disk A: is automatically assigned as 
the transmitting station's logical disk M. Then, automatically 
via the PIP.COM program, the contents of the file name specified 
are sent over the net and appended to the receiving station's 
MAIL.MAL file. The contents of the specified file name are 
retained at the transmitting station. 



FILE TRANSFERS OVER THE NETWORK 

To transfer a file from one workstation to another, the 
command COPY is employed. For example, the following sequence at 
Workstation #1: 

+ + 

<A0>ASSIGN C:=B:2<RET> 

Device assigned 

<A0>COPY As=C:MYFILECV]<RET> 

<A0> 

+ + 

would result in a file called MYFILE residing on disk B: at 
Workstation #2 being copied onto the A: disk at Workstation #1. 

Note - The CP/M command "PIP" may be used in place of COPY. 

CHANGING USER ClD] 

Depending upon the Privilege Level assigned, certain USER 
[ID]'s are permitted to change to other USER [ID]'s. For example, 
assume an operator is currently logged in as USER [3] (name = 
SUSAN) and wishes to change to USER [1] (disk A is the currently 
logged disk). At the prompt, type: 



<A3>USER<RET> 

[3] User: SUSAN 7003 
<A3> *"*+ — 3=0riginal Login USER [ID] 

::+ 0=Reserved 

:+ 0=Extended Privilege 

+ 7=Privilege Level 



Typing USER without a USER [ID] displays the current status, 
i.e., USER [3], name SUSAN, Privilege Level "7". Note that Privi- 
lege Level "7" permits changing USER ID's. Now type: 
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+ 1. 

<A3>USER 1<RET> 

[1] User: SUSAN 7003 
<A1> 



USER [3] is now logged in as USER [1] and may access all USER [1] 
files, however, user name and privileges do not change . 

If an attempt is made by a user who is not privileged to 
change USER [ID]'s, an error message is generated. For example, 
assume an operator is currently logged in as USER [1] (name = 
FRANK) and wishes to change to USER [4]: 



+ 

<A1>USER 4<RET> 

? Not privileged 
<A1> 



To check the user status of USER [1], type: 

+ + 

<A1>USER<RET> 

[1] User: FRANK 1001 

<A1> 



This will verify that USER [1] has a Privilege Level "1" and 
therefore may not change USER [ID]'s. 



ASSISTANCE FROM ULC-OPSnet 

Assistance in use of ULC-OPSnet commands is available 
through the "OHELP" command. For example, if you are experiencing 
error messages when attempting to use the ASSIGN command, type: 

+ + 

: <A0> OHELP ASSIGN<RET> : 

+ + 

Information concerning the ASSIGN command will be displayed. The 
"OHELP" command may also be abbreviated to simply H. For 
example, if the command: 

+ + 

<A0>H *<RET> : 

+ + 

is entered, then a list of subjects to which help is available is 
displayed. The command: 

+ + 

: <A0>H<RET> : 

+ + 

will display information on how to use the HELP command itself. 
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BRINGING UP THE NETWORK 

In Chapter 3 under the heading "INSTALLATION" you were 
introduced to the method for bringing up the network. The fol- 
lowing sequence should be observed each time the network is made 
ready for use. 



STEP 

1. Make sure all disk drives 
are empty . 

2. Turn on all microcomputers. 

3. Turn on all Connector 
Adapters (NET READY lights 
should be on) . 

4. Place a systems disk 
(contains CP/M and ULC- 
OPSnet files) in drive A 
of each microcomputer. 

5. Boot CP/M. 

6. Load ULC-OPSnet*. 

7. Log each station onto 

ULC-OPSnet. 

8. Supply password. 

9. Identify each station. 

10. Network is ready for use. 



COMMANDS 



Varies with computer type. 
A>ULCOPS<RET> 
<A0>LOGIN <User ID><RET> 

Password: ****<RET> 

<A0>INET KAYPRO < station 
ID><RET> 



Note: If a Gatekeeper station — use *ULCOPSG" instead of 
*ULCOPS". Gatekeeper station m ust be brought up 
first . Workstations cannot initialize their net- 
work protocols without first receiving authori- 
zation from the Gatekeeper. INITIALIZATION is the 
only instance where the Gatekeeper must be opera- 
tional. Once all Nodes are "NET READY", operation 
may continue without the Gatekeeper being on-line. 



LEAVING THE SYSTEM 

To log off ULC-OPSnet, enter: 

+ 

< A0 >LOGOUT<RET> 



Note that even though an operator at a Node may have Logged-out, 
the background partition (also known as the serving partition) is 
still operational. 
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CHAPTER 7 
OPERATIONAL AND APPLICATIONS CONSIDERATIONS WITH ULCnet 



INTRODUCTION 

Creating an optimum operating environment with ULCnet will 
take some practice and planning. Since every station on the 
network acts as both a server to other stations on the net and as 
an information processor for its operator, the operating policies 
need to be more stringent than in a stand-alone environment. 
Plans for applications need to include groupings of employees 
requiring access to particular programs and data files, as well 
as consideration for how to store and back up sensitive or confi- 
dential data. When planning for the purchase of application 
software, consideration must be given to the TPA (transient 
program area) requirements of the application, what multi-user 
enhancements the application is designed for or which changes 
must be made to provide for multi-user operation, and how shared 
devices, such as printers, are to be interfaced to the applica- 
tion. Other considerations in this Chapter include such items as 
the physical placement of printers for paper changing, setup of 
systems and device assignments using INITIA..INI and 0SUB.COM, and 
activity tracking using the Gatekeeper. 

OPERATING PROCEDURES 

1. Power, LOGging IN and LOGging OUT 

Power to all systems and peripherals on the network should 
remain on until the last user leaves at the end of the day. In 
this way, all users will have access to any of the system 
resources that may be required. Unauthorized use of the network 
is prohibited simply by specifying that each operator perform a 
LOGOUT when finished. When a system is LOGged OUT, the back- 
ground serving partition is still available to other operators on 
the network. Only the foreground partition (the partition that 
permits access to the keyboard and console) is disabled after a 
LOGOUT . 

Suppose Mary normally uses the system specified as "node M", 
Joe uses "node J", Lisa sits at "node L" and George is the 
Gatekeeper at "node G". Mary and Joe (nodes M and J) both have 
printers attached to their systems and Lisa and George (nodes L 
and G) have data bases on hard disks attached to their systems. 
When Mary leaves for lunch and George goes home early, each of 
their systems have resources attached that may be required by 
other users. If George and Mary simply LOGOUT when they leave 
their systems, Lisa and Joe still have access to the data base at 
node G and the printer at node M. They can also MAIL material to 
George and Mary, even though George and Mary have left. No one 
else may sit down to use nodes M and G, however, without first 
going through a LOGIN and having a valid password already on the 
ACCT.SYS file at each of those nodes; system integrity and full 
security are thus maintained. 
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2. Grouping Classes of Users and USER [ID]'s by Application 
Requ i r ement s 

When setting up major applications under ULCnet, it is 
advisable to determine which employees will require access to the 
various applications and files, and set up USER [ID]'s and Privi- 
lege Levels accordingly. For example, if all employees requiring 
access to accounting files are USER [5], and all of the actual 
accounting files are put into USER [5] area, then non-accounting 
employees with a Privilege Level of 1, or 5 and a USER [ID] other 
than 5, will not ever have access to the accounting files. Thus 
other employees may access physical disk drives containing 
accounting files, but may not change USER [ID]'s to USER [5] and 
actually see the files or change the files in USER [5] area. 

In the previous example, suppose George is the Chief 
Financial Officer, and that all of the accounting files are on 
his system at "node G," in USER [5] area. Joe and Lisa are 
accounting clerks, and process the accounting applications. Mary 
is in charge of sales, and needs access only to customer and 
prospect files. These files are all kept on the hard disk drive 
at node L, Lisa's station, in USER [3] area. It is desirable for 
George to be able to access both accounting and customer 
information, Lisa and Joe only accounting information, and Mary 
only customer files. All four employees must be able to LOGIN to 
other systems in the event their own station is not functioning 
properly. The ACCT.SYS files at each station might be set up as 
follows: 

a. At node G: 



User 


1 
2 
3 
4 
5 
6 
7 
8 
9 



Paswrd 

Boss 
Buck 

Sell 

#'sl 



React vl . 3 
Station Local 
Name Privs 



XPRVS 



NETWRKMGR 
GEORGE 

MARY 

JOE/LISA 



7 


00 


7 


00 


5 


00 


5 


00 



*************************** 

* (1) - Add/modify entry * 

(2) - Delete entry 

( 3 ) - Change Station 

(4) - Save Changes 

(5) - Exit / No changes 
*************************** 



Enter selection 
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George is the primary user, and, even though he LOG's in as 
USER [1], he may change to any other USER [ID] because he is a 
Privilege Level 7. Lisa, Joe, and Mary can all use George's 
network station, if necessary, but cannot change USER ClD]'s, and 
therefore cannot have access to files they should not use. 

b. At node L: 



User 


1 
2 
3 
4 
5 
6 
7 
8 
9 



Paswrd 



React vl . 3 
Station Local 
Name Privs 



*************************** 

* (1) - - Add/modify entry * 

* (2) - Delete entry 

* (3) - Change Station 

* (4) - Save Changes 

* (5) - Exit / No changes 
*************************** 



Enter selection 



XPRVS 



Boss 
Buck 


NETWRKMGR 
GEORGE 


7 
7 

5 

5 


00 
00 


Sell 


MARY 


00 


Lisa 


LISA 


00 









Lisa has her own password as USER [5]. Since Joe can use 
George's system or Mary's system if his is out of use, he doesn't 
require a password here. Mary also has a password allowing her 
access to this system if hers is out of use. All three have 
Privilege Level 5 which permits them only to use files within 
their own USER [ID]. Both George and the network manager have 
access to this and all other nodes with Privilege Level 7. Note 
that only the network manager can change Passwords, USER ClD]'s 
within the ACCT.SYS file, and Privilege Levels since the network 
manager only can LOGIN as USER [0] and therefore access 
REACT . COM . 

The same logic applies for the assignment of USER ClD]'s, 
Passwords, and Privilege Levels at nodes J and M. 
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c. At node J: 



User 


1 
2 
3 
4 
5 
6 
7 
8 
9 



Paswrd 


React vl 
Station 
Name 


.3 

Loc 


:al 
Privs 


Boss 
Buck 


NETWRKMGR 
GEORGE 


7 
7 


Sell 


MARY 


5 


Hotl 


JOE 


5 



*************************** 

* (1) - Add/modify entry * 

* (2) - Delete entry * 

* (3) - Change Station * 

* (4) - Save Changes * 

* (5) - Exit / No changes * 
*************************** 



XPRVS 

00 
00 

00 

. 00 



Enter selection 



d. At node M: 



+ + 



User 


1 
2 
3 
4 
5 
6 
7 
8 
9 



Paswrd 

Boss 
Buck 

Revn 

#'sl 



React vl . 3 
Station Local 
Name Privs 



XPRVS 



NETWRKMGR 
GEORGE 

MARY 

JOE /MARY 



7 


00 


7 


00 


5 


00 


5 


00 



*************************** 
* (1) - Add/modify entry * 



* 
* 
* 
* 
*************************** 



(2) - Delete entry 

(3) - Change Station 

(4) - Save Changes 

(5) - Exit / No changes 



Enter selection 
+ + 
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In this example, a number of different objectives have been 
accomplished. 

1. All employees have Passwords permitting each one to use 
any of the systems as required. 

2. The Passwords chosen consist of many combinations of 
upper/lower case letters, numbers, and special 
characters . 

3. USER [lD]'s were chosen to segment applications and 
application files. 

4. Privilege Levels were assigned to limit file access to 
those employees authorized to work with the files. 

5. The Gatekeeper station was assigned to the Chief 
Financial Officer to permit him to utilize the WH0.COM 
command and keep track of applications in execution. 

APPLICATIONS CONSIDERATIONS 

1 . Choosing Application Software 

The considerations involved in choosing "off the shelf" 
application software are much more important in the networked 
environment than in the stand alone, single user environment. 
Ease of use and operator interface are still necessary ingre- 
dients to evaluate a software package, but of more importance are 
such items as required memory, conformance to CP/M 2.2 standards, 
ease of custom configuration and availability of some source code 
modules for custom integration. 

a. Memory Required 

ULC-OPSnet utilizes about 7K bytes of memory over and above 
CP/M. It is thus important to determine how much memory is 
available after loading ULC0PS.COM or ULC0PSG.COM for applica- 
tion programs. CP/M conventions hold that application programs 
should begin at memory location 0100 Hex and end at an address in 
memory one byte before the beginning of the resident part of the 
operating system. CP/M communicates the "termination of TPA" 
address to the application program by storing this address in 
memory locations 0006,7 Hex. Since ULC-OPSnet acts as a "shell" 
to CP/M, ULC-OPSnet alters locations 0006,7 Hex to let applica- 
tions programs know how much memory is available for the programs 
to load in and utilize. 

The KAYPRO Models 2 and 4, have 50K bytes of memory left for 
applications programs after ULC-OPSnet takes over. The KAYPRO 
Model 10 has a larger BIOS, and therefore less memory available 
for application programs. After ULC-OPSnet is loaded, the Model 
10 has approximately 48K bytes of memory for program execution. 
The available TPA, or Transient Program Area, must be considered 
when deciding which applications to execute on various machines. 
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You must first insure that no application program requires 
more than the net available memory to run. This information 
should be available from the application supplier or in the 
application documentation. 

Generally, applications written to run under either CP/M or 
MP/M (the multi-user operating system from Digital Research, 
Inc.) are good candidates for running under ULC-OPSnet. These 
applications will, in general, use less memory (MP/M permits only 
a 48K byte TPA) and will be written to more closely follow 
Digital Research programming conventions. 

b. Conformance to CP/M 2.2 Standards 

Digital Research thoroughly documents procedures and 
standards for creating applications programs under CP/M 2.2. 
Compilers, like CBASIC and R/M Cobol and interpreters like dBASE- 
II and MBASIC follow these standards to the extent that the 
programmer uses only the commands available. Unfortunately, pro- 
grams written in Assembler or written in compilers and inter- 
preters using Assembler sub-routines do not always follow CP/M 
standards and conventions. ULC-OPSnet requires that certain of 
these conventions are followed in order to gain the flexibility 
of virtual device assignment on the network. Thus, a few applica- 
tion programs that will operate under CP/M w ill not operate 
properly under control of the network even though they may not 
require any more than the available amount of memory. 

It is important to establish that the applications you 
intend to utilize on the network: 

1) Will run under standard CP/M version 2.2. 

2) If direct console I/O is performed, the application does 
so only through BDOS function 6 and not through BIOS 
calls. 

3) Do follow CP/M 2.2 BDOS calls for all file operations. 

4) Do not utilize bits in the File Control Block normally 
unused by CP/M. (These are used by ULC-OPSnet to specify 
files as LOCKED/UNLOCKED, PRIVATE /SHARED, etc.) 

5) Do not use memory locations 0040 and 0041 Hex (normally 
unused by CP/M) except as documented in this User's 
Guide, Chapter 8, "Programming Considerations for Multi- 
User Applications." 

Information about how an application has been programmed 
should be available from your applications supplier. 

c. Ease of Custom Configuration 

Most professionally written applications provide the 
purchaser the ability to configure the application to take full 
advantage of CP/M? i.e., configure input and output for any legal 
CP/M logical device, configure consoles and CRT's for the 
attributes of the physical device used, etc. Some application 
programs, like those produced by Micropro International, go a 
positive step beyond that. WordStar, for example, even permits 
the purchaser to custom configure hardware, menus, logical 
devices for location of overlay files, etc. 
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It is important to evaluate the designed-in configuration 
flexibility of an application when considering it for the network 
environment. For example, if an application program does not 
permit you to select the logical disk drive on which the program 
files and overlay files will be located, you may have difficulty 
assigning logical devices so that multiple users may have access 
to it. Likewise, if you do not have the flexibility of deter- 
mining the file extension name of required overlay files (.OV? is 
the normal CP/M convention, and the extension automatically 
searched for by ULC-OPSnet) you may be required to waste disk 
space with multiple copies of such files because ULC-OPSnet will 
not automatically search for any overlay file extension other 
than .OV?. 

Flexibility in the assignment of logical devices for the 
data files is also important. If any application, for example, 
demands to see the data files only on disk B:, then there is 
little opportunity for the user to determine his own logical 
device assignments. 

Make certain that applications you intend to use on the 
network can address printing output to the logical CP/M LST: 
device. In this way, your applications will be able to spool all 
printed output to some predefined file to actually be printed in 
a batch mode at some later time. 

d. Source Availability for Custom Integration 

If some of the applications you are considering do not have 
an extensive pre-designed custom installation capability, like 
those available from Micropro International, then it is advisable 
to establish the availability of some source code modules for 
customization . 

For example, suppose that batch printing of major or summary 
reports from an application is acceptable, but that it would be 
desirable to have some short reports or information be submitted 
to the spooler for immediate printing by an operator. In most 
cases, this can only be accomplished by having access to the 
print module source code to enable the user to build in the 
special commands to these small reports to be printed by the 
spooler immediately. 

2. Configuring an Example Application for ULCnet 

Using the example at the beginning of this Chapter, suppose 
that George (the Chief Financial Officer) has chosen an 
accounting application. The application system he has decided to 
buy might be configured as follows: 

a. The application, called "MEGACCOUNTING", contains a main 
program module, ACC0UNT.COM, five overlay program 
modules, GL.OVL, AR.OVL, AP.OVL, PR.OVL, AND RPT.OVL, 
and a program module ACTINSTL.COM, used to install and 
configure the MEGACCOUNTING system. 
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b. George decides to store the program modules as well as 
the data modules in USER [5] area even though MEGAC- 
COUNTING provides passwords for access to data files. 
George knows that by storing the programs and data files 
in USER [5] area, only those personnel with access to 
USER [ID] [5] will have access to the application. 
George further determines that all of the program 
modules will easily fit on the C: partition of his hard 
disk, but that the accounting data base will grow to 
almost 4 Megabytes, so that he must put the data files 
on partition A: of his hard disk. 

c. Joe and Lisa will run MEGACCOUNTING for most of the 
input, updates, and reports. The printer located at 
Joe's station (node J) will be used for general ledger 
reports, statements, checks, etc. The small dot matrix 
printer at node N, (Norman, the network manager), will 
be used mainly by George to produce small detail reports 
and quick reference status reports. 

d. George's first task is to decide on common logical 
device assignments for the physical disk drives on which 
the data and programs will reside. This is necessary 
because MEGACCOUNTING does not provide the ability to 
dynamically assign disk devices during execution; the 
disk assignments must be pre-determined and installed 
with the ACTINSTL.COM program. Since MEGACCOUNTING will 
execute separately in each one of the systems, the 
ACC0UNT.COM program must have a device assignment 
structure that is common to each system running MEGAC- 
COUNTING. George decides to install MEGACCOUNTING to 
look for the .COM and .OVL files on logical disk K: 
(George's physical disk C:) and to look for the data 
files on logical disk L: (George's physical disk A:). 

e. Now George is ready to build the INITIA.INI files at 
each node. By building INITIA.INI files at every node 
in the USER [5] area, every time Joe or Lisa LOGIN at 
any station, they will be set up to run MEGACCOUNTING. 
George starts at his own station, building an INITIA.INI 
file in USER [5] in the event either Joe or Lisa must 
use his system. George uses WordStar to build the 
INITIA.INI files. 

+ . + 

A>ULCOPSG<RET> 

ULC-OPSnet vl . 70 Gatekeeper - Node 8 
Copyright 1983 (C) by Aquinas Inc. 

<A0>LOGIN 1<RET> 

Password: **** (type Buck) 

Logged-in on ULC-OPSnet vl . 70 Gatekeeper-Node 

Copyright 1983 (C) by Aquinas Inc. 

[1] User: GEORGE 7001 

<A1>INET KAYPRO 

Gatekeeper running... 
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+ + 

: <A1>USER 5<RET> : 

: [5] User: GEORGE 7001 : 

: <A5>WS<RET> : 

+ + 

Once into WordStar, George uses the non-document option 
by typing N. When asked by WordStar for a filename to 
edit, George responds with A: INITIA.INI. After the 
WordStar file editing help menu appears, George begins 
entering as follows: 



+- 



INET KAYPRO <RET> 
TTY GAG<RET> 



ASSIGN C 
ASSIGN D 
ASSIGN E 
ASSIGN F 
ASSIGN G 
ASSIGN H 
ASSIGN I 
ASSIGN K 
ASSIGN L 
SPOOL J<RET> 
INITIALIZE <RET> 
K:<RET> 



=C:<RET> 

=Ds<RET> 

=E:<RET> 

=A:M<RET> 

=A:J<RET> 

=A:L<RET> 

=A:N<RET> 

=Cs<RET> 

=A: <RET> 



George now enters *KX, and the file is stored. Now 
every time an operator performs a LOGIN 5 at node G, the 
system at node G will be set up to: 

1) Initialize the network as the Gatekeeper. 

2) Prohibit messages from appearing on the screen if 
the foreground partition of node G is executing a 
program. 

3) Address all of the local hard disk partitions and 
the local floppy disk. 

4) Have assigned all of the A: disks at other nodes to 
be able to access files. • 

5) Additional addresses for the local C: and A: disks 
of K: and L: respectively, so that MEGACCOUNTING 
will run properly. 

6) Printed output will be spooled to the printer at 
node J. 

7) The logged disk will be K: so that when ACCOUNT is 
entered, the operating system will look to 
ACC0UNT.COM on the logical K: disk, which is also 
the physical C: disk locally. 

f. Prior to entering WordStar, George had executed the USER 
5<RET> command, and was in USER [5] area when the 
INITIA.INI file was created and stored. Now George 
creates the INITIA.INI file at Lisa's station, node L. 
As summing that power is on and that ULC-OPSnet is active 
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in node L, George can create the INITIA.INI file by 
performing the following: 

+ + 

: <A5> ASSIGN F:=AsL<RET> : 

: Device F: assigned : 

: <A5>WS<RET> : 

+ + 

Since George's active USER [ID] is [5], and since he has 
already assigned his F: disk as the physical A: disk at 
node L, when the WordStar no file menu is displayed, 
George will type N, for non-document option, and 
F:INITIA.INKRET> for the file to be created. George 
will create the INITIA.INI file for Lisa on his system, 
but it will be stored on the physical A: disk at node L 
in USER [5] area. George creates the file as follows: 



INET KAYPRO L<RET> 
TTY GAG<RET> 



ASSIGN C 
ASSIGN D 
ASSIGN E 
ASSIGN F 
ASSIGN G 
ASSIGN H 
ASSIGN I 
ASSIGN K 
ASSIGN L 



=Cs<RET> 

=Ds<RET> 

=Es<RET> 

=A:M<RET> 

=AsJ<RET> 

=A:G<RET> 

=AsN<RET> 

=CsG<RET> 

=AsG<RET> 



SPOOL J<RET> 

INITIALIZE<RET> 

Ks<RET> 



George now enters "KX, and the file is stored at node L 
in USER [5] area. Now every time Lisa performs a LOGIN 
5 at node L, the system at node L will be set up to: 

1) Initialize the network as a Workstation, node L. 

2) Prohibit messages from appearing on the screen if 
the foreground partition is executing a program. 

3) Address all of the local hard disk partitions and 
the local floppy disk. 

4) Have assigned all of the A: disks at other nodes to 
be able to acccess files. 

5) Additional device names for the physical C: and A: 
disks at node G of K: and L: respectively, so that 
MEGACCOUNTING will run properly. 

6) Printed output will be spooled to the printer at 
node J. 

7) The logged disk will be K: so that when ACCOUNT is 
entered, the operating system will look to 
ACC0UNT.COM on the logical K: disk, which is also 
the physical C: disk at node G. 
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The procedure and logic for creating the other 
INITIA.INI files for USER [5] on other nodes is similar, 
and will not be shown here. 

g. George wants to create one more INITIA.INI filer his own 
in USER [1] at node G, and any other node George may 
want to operate. Assume that George has just completed 
the last INITIA.INI file in USER [5]. He would now: 

+ + 

: <A5>USER 1<RET> : 

: [1] User: GEORGE 7001 : 

: <A1>WS<RET> : 

+ + 

Since George is now in USER [1], he enters the non- 
document option of WordStar with a N and enters the 
desired filename A:INITIA.INKRET> knowing that this 
INITIA.INI file will be stored at his physical disk A:, 
USER [1]. George completes his INITIA.INI file as 
follows: 



+■ 



INET KAYPRO<RET> 
TTY GAG<RET> 



ASSIGN C 
ASSIGN D 
ASSIGN E 
ASSIGN P 
ASSIGN G 
ASSIGN H 
ASSIGN I 
ASSIGN K 
ASSIGN L 
ASSIGN J 
ASSIGN N 
SPOOL N<RET> 
WHO<RET> 
INITIALIZE<RET> 



=C:<RET> 

=Ds <RET> 

=Es<RET> 

=AsM<RET> 

=A:J<RET> 

=A:L<RET> 

=A:N<RET> 

=Cs<RET> 

=A: <RET> 

=B:L<RET> 

=B:N<RET> 



George now enters ~KX, and the file is stored. Now 
every time George performs a LOGIN 1 at node G, the 
system at node G will be set up to: 

1) Initialize the network as the Gatekeeper. 

2) Prohibit messages from appearing on the screen if 
the foreground partition is executing a program. 

3) Address all of the local hard disk partitions and 
the local floppy disk. 

4) Have assigned all of the A: disks at other nodes to 
be able to access files. 

5) Additional addresses for the local C: and A: disks 
of K: and L: respectively, so that MEGACCOUNTING 
will run properly. 

6) Access the B: disk at node L and the B: disk at node 
N. 
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7) Printed output will be spooled to the printer at 
node N. 

8) The WHO.COM command will be executed to show George 
who is on ULCnet and what each LOGged IN operator is 
doing. 

3 . Printing in the Network Environment 

In concept, printing in the network environment is very much 
like printing in the large data processing batch environment. 
Since printers require relatively little processor resource as 
compared with, for example, engineering, spread sheet, or data 
base applications, the printing function in large systems is 
allocated to a low priority background task called "spooling". 
In the typical stand-alone microprocessor environment, applica- 
tion programs communicate directly with the printer during the 
execution of the application. Printing represents on the average 
only ten to fifteen percent of the time used in most microproces- 
sor environments, so the printer is idle most of the time. ULC- 
OPSnet implements a very powerful facility allowing any printer 
on the network to be used by any system on the network. The 
printing function in ULC-OPSnet uses processor cycles only when 
they are available so as not to adversely impact the more 
important foreground task or disk serving task. Thus printers 
connected to systems on ULCnet may be used to print output from 
many different nodes while operators at the systems with printers 
attached are performing other tasks. Clearly, this printing 
architecture can only work if disk resident print files are 
presented to the background "spooling" task instead of direct 
printed output from the application. The result is better utili- 
zation of printer resources and operator time. It will take some 
practice and planning to realize the full benefit of the ULC- 
OPSnet print spooling facility. The print routines in some 
applications may also require small changes. 

In the previous example, suppose that George decides that 
all major report and statement printing will occur as "spooled" 
printing. Since the main printer used is at node J, George makes 
Joe responsible for paper changing where special forms are re- 
quired. Lisa has a hard disk at node L, so George decides to use 
the C: disk partition at node L to store all print files prior to 
actually printing. Recall from the INITIA.INI setup that George 
decided to address the physical C: disk at node L as the logical 
J: disk, and that this device designation would be common 
throughout accounting applications. George now runs the MEGAC- 
COUNTING installation program, ACTINSTL.COM, and chooses the 
options which will: 

1. Force all printing operations to address the printer as 
the CP/M LST: device. 

2. Sets up each print module in MEGACCOUNTING to call the 
ULC-OPSnet ASSIGN command, and ASSIGN the LST: device to 
a filename at disk J:, where the filename ASSIGNed 
denotes the type of printing to be done. 

3. Setup the appropriate print driver for the type of 
printer physically attached to Joe's station. 
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For example, suppose that the printer connected to the 
system at node J is a Diablo 630, and that special forms are 
required for statements , payroll checks , accounts payable checks , 
and invoices . George decides to set up the print modules for 
each of these applications in MEGACCOUNTING to ASSIGN the LST: 
device to a file name that denotes the type of printing. 

1. The module to produce statements will call the ASSIGN 
command to: ASSIGN LST:=J:STATEMNT.PRN. 

2. Likewise, the module to produce payroll checks will call 
the ASSIGN command to: ASSIGN LST:=J:PAYROLCK.PRN. 

3. Each additional print module is set up to ASSIGN the 
LST: device to a filename on logical disk J: to corres- 
pond to the job name or special forms required. 

George must now add to his operations procedures for Joe and 
Lisa the instructions for QUEUEing the files as application print 
files are completed. An example entry in the operations 
procedures might be as follows: 

a. Under the section for running payroll : 

After the payroll job has completed and the main menu is 
displayed, push the 9 key. This will exit to the system prompt 
<K5>. Now do the following: 

+ + 

<K5>FINISH<RET> 

LST: file closed as J : PAYROLCK . PRN 

<K5>QUEUE J: PAYROLCK. PRN/F<RET> 

<K5> 

+ + 

You may now go on to the next task. 

b. Under the section for running printers : 

If the printer attached to your station stops printing and 
the previous printing job is finished, at your first opportunity 
to stop what you are doing and get back to the system prompt 
"<K5>", do the following: 



: <K5>QUEUE<RET> 

+ 



The system will tell you if anything has been submitted to 
the spooler to be printed and what the special requirements are. 
If the system responds with: 

+ + 

<K5>QUEUE<RET> 

Currently printing: J : PAYROLCKPRN Forms=Special (etc.) 
Queue file pending: X : XXXXXXXXXXX Forms=Normal (etc.) 

<K5> 
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... and the printer is not printing, it means that the print 
file PAYROLCK.PRN is ready to print, but the payroll check forms 
must first be inserted correctly into the printer. Insert the 
check forms, noting the starting check number, and tell the 
system spooler to begin the printing operation by keying in QUON 
as follows: 

+ + 

<K5>QUEUE<RET> 

Currently printing: J : PAYROLCKPRN Forms=Special (etc.) 

Queue file pending: X : XXXXXXXXXXX Forms=Normal (etc.) 

<K5>QUON<RET> 

<K5> 

+ ■ + 

The system will now begin to print the checks and you may go 
on to the next task. 

Note that when the /F switch is used by the requesting node 
(i.e., the station from which the QUEUE command was originally 
issued to cause the file to print), the background spooler is 
turned off (i.e., put into a QUOFF state) at the node on which 
the file is to be printed when the file comes to the head of the 
print queue. This feature is implemented to permit the operator 
at the printing node to interrogate the queue and load special 
paper, if required. 

It is important to try a variety of configuration techniques 
and operating procedures to optimize printing with ULC-OPSnet. 
Your applications supplier should be able to assist you in 
identifying the particular printing modules that you may want to 
optimize for spooling in the applications you purchase. 
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CHAPTER 8 
TECHNICAL CONSIDERATIONS FOR PROGRAMMING AND OPERATIONS 



PLACEMENT OF .COM AND .OV? FILES 

ULC-OPSnet has a designed-in automatic search algorithm for 
program and overlay files. The rationale for autosearch is to 
reduce the number of copies of .COM and ,0V? files occupying disk 
space in the network environment. There are three forms of the 
RUN command which activate autosearch: 

1. Implied run (.COM file name without extension). 

2. R <dev>:<.C0M file name without extension> . 

3. RUn <dev>:<.COM file name without extension> . 

Each of these forms invokes a different search path for the 
desired program. The following table delineates the search path 
for each form of the RUN command looking for the program XX.COM: 



d=current logged drive : 

u=active USER[ID] :1st Search to: 

N=any assigned disk : 



:2nd Search to: 



<du>XX<RET> 


:A:USER 


C0] 


:d:USER 


[u] 


<du>R XX<RET> 


:d:USER 


[0] 


:A:USER 


[0] 


<du>R N:XX<RET> 


:N:USER 


[0] 


: A: USER 


[0] 


<du>RUn XX<RET> 


:d:USER 


[u] 


: A: USER 


[0] 


<du>RUn NsXX<RET> 


:N:USER 


[u] 


:A:USER 


[0] 



+ + 

For example, suppose that you are operating the system at 
node 7 and desire to execute the program ZER0.COM located on the 
physical disk C:, USER [0], at node 3. You could run ZER0.COM by 
performing any of the following: 

+ , + 

<A0> ASSIGN Cs=C:3<RET> 

Device C: assigned 

<A0>R C:ZERO<RET> 

(or) 
<A0>C:<RET> 
<C0>ZERO<RET> 

(or) 
<C0>RUN ZERO<RET> 

(or, if eg. USER [1]) 
<A1>ASSIGN C:=C:3<RET> 
Device C: assigned 

<A1>R C:ZERO<RET> 

(or) 
<A1>C:<RET> 
<C1>R ZERO<RET> 
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The autosearch algorithm for .OV? files is absolute: .OV? 
files will always be searched on the same logical disk and from 
the same USER [ID] as the .COM program that calls for the over- 
lay. While this method makes the decision on the placement of 
all .COM files and their respective overlays relatively simple, 
it causes confusion when using the PIP.COM program or any other 
file copy routine. Since ULC-OPSnet overrides the logical disk 
location call from a .COM program to the logical disk from which 
the .COM program was loaded, copying .OV? files requires that the 
autosearch feature for .OV? files be temporarily disabled. This 
is accomplished with the OVOFP command. Suppose you desire to 
copy WS.COM, WSMSGS.OVR, and WS0VLY1.0VR from logical disk D: to 
logical disk F:. If you were to try this w ithout first turning 
off the .OV? autosearch, the following would occur: 



<A0>PIP Fs=D:WS*.*CV0]<RET> 

COPYING- 

WS . COM 

WSMSGS . OVR 

NO FILE: =D: WSMSGS .OVR 

<A0> 



In this example, WS.COM was found, but the first overlay 
file, WSMSGS.OVR, was not found because ULC-OPSnet overrode the 
PIP.COM request to find WSMSGS.OVR on the logical D: disk, and 
instead, searched the disk from which the .COM file (PIP.COM) was 
loaded, disk A:. The command would have been successful if 
preceded by the OVOFF command as follows: 



<A0>OVOFF<RET> 

<A0>PIP Fs=D:WS*.*CV0]<RET> 

COPYING- 
WS . COM 
WSMSGS . OVR 
WS0VLY1 . OVR 

<A0>OVON<RET> 

<A0> 



As the example indicates, do not forget to turn .OV? autosearch 
on again after completing copying operations. 

The Autosearch feature of ULC-OPSnet, in combination with 
the system security features, can be used to advantage in the 
operational environment where a variety of employees with differ- 
ing responsibilities and experience levels have access to the 
system. If all required .COM and .OV? files are kept in USER [0] 
area, (for example), employees with access to accounting files in 
USER [7] could not see the .COM and .OV? files in their respec- 
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tive directories, but would be able to execute the applications 
when following their written procedures by typing in the appro- 
priate .COM file names. Other unauthorized employees would be 
able to execute the accounting programs, but would not have 
access to the accounting data files. 

OPERATIONAL PERFORMANCE NOTE: It is always advisable to keep as 
much of the program code (files ending in .COM, .OV? f .BAS, .CMD, 
etc.) as possible on locally available disk storage. Access over 
ULCnet to records in a data file, message switching, and spooling 
usually require only a small number of network packets per opera- 
tion. If multiple operators must load program application code 
over the network as well, user response time may be severely 
affected, as program loads may require upwards of 400 packets 
before any operator activity may be accomplished. This situation 
is particularly exacerbated when a network is organized such that 
all users must load program code and data from one node. Remem- 
ber, the concept of local area networking is one of Distri- 
buted Processing ; since all micro-processors in the networked 
systems are approximately equal in instruction execution speed, 
it is best to distribute the probable processing load as much as 
possible between multiple systems. 

MULTI-USER FILE OPERATIONS UNDER ULC-OPSnet 

ULCnet is a distributed intelligence architecture, that is, 
applications execute independently of one another in separate 
systems. There is no centralized file server, and no MP/M system 
is required to act as the server controller. In the ULCnet envi- 
ronment, multiple simultaneous executions of an application may 
also have common file(s) open at the same time. 

In this regard, ULC-OPSnet provides a momentary record lock 
to prohibit two or more requests from issuing simultaneous 
"writes" to the same physical record. There is not, however, an 
automatic method with which to ensure proper file appending when 
two or more systems have a common file open. Since the back- 
ground serving partition can only provide data and file control 
block information to the application, there is no way to communi- 
cate to the foreground partition of a requesting system the 
status of a particular record. The CP/M file structure has no 
provision in the file control block for this kind of dynamic 
status information. To solve this multi-user data base problem, 
ULC-OPSnet has implemented a convention which, if followed in 
application logic, will result in the ability to use dynamically 
alterable common data bases in a multi-user environment. The 
convention was designed specifically for dBASE-II (c), but will 
work with virtually any application generator, compiler or inter- 
preter with the ability to "Peek" and "Poke" a specific memory 
location. 

The multi-user convention is designed around two "flag 
bytes," the contents of which are determined by both ULC-OPSnet 
and the application program. The flag bytes are in memory loca- 
tions 64 (40H) and 65 (41H). Location 64 is the file status byte 
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the application looks for to determine if the file just opened is 
"locked" and currently in use by another user, or has just been 
locked and is available for update by the application. Location 
65 is used by the application to tell ULC-OPSnet if the file just 
requested is to be used to read only , or will be used with the 
intent to both read and w rite . Any file intended to be used in a 
multi-user environment must end in a physical file extension of 
.DBU . The application program may call for the open of a file 
with the .DBF extension; ULC-OPSnet will look for the .DBU file 
extension automatically if it does not find the file with .DBF. 

Functionally, the application must POKE location 65 with 
if the file is to be opened as read only or if the file is to 
be opened as read/ w rite . After issuing an OPEN (or USE), the 
application must PEEK at location 64. If location 64 = 0, the 
file just opened is now locked to other users, and the applica- 
tion may continue with the process, update the file, and close 
the file. If location 64 is not (^0)the file just opened has 
already been opened and locked by another user. If the applica- 
tion had previously POKEd a 1_ into location 65, signifying to 
ULC-OPSnet the intent to read only , the application may proceed 
with a normal read and close the file. If, on the other hand, the 
application had previously POKEd a Q_ into location 65, indicating 
to ULC-OPSnet the intent to write to the file, the application 
must wait and retry the OPEN prior to proceeding. 

If multiple files are to be "used" at the same time, the 
value of location 64 after the file is opened must be saved . 
Likewise, before the file is closed the value of location 64 m ust- 
be restored^ For example, in dBASE-II*, after the USE statement 
to open a file, do a STORE PEEK(64) TO FSTAT1. Then before the 
closing USE, do a POKE 64,FSTAT1. Make certain there is a sepa- 
rate variable for each file opened. If only one file at a time is 
to be used, this procedure is not nessesary. This procedure is_ 
necessary when more than one file is to be opened at one time, 
regardless of whether or not the files are PRIMARY or SECONDARY. 

The ULC-OPSnet Gatekeeper release diskette contains a file 
called APPLNOTE.CMD. This is a example dBASE-II source program 
file implementing the ULC-OPSnet file lock convention, and util- 
izes the small files called TEST.NDX and TEST. DBU. The program is 
a useful example for any application requiring file lock. The 
file lock convention will also work with applications written in 
other programming languages. MBASIC** (c), for example, supports 
the same PEEK and POKE commands as dBASE-II. 

OPERATIONAL NOTE: ULCnet creates a truly distributed processing 
network. Any file may be located anywhere physically in the Net, 



dBASE-II is a trademark of Ashton-Tate. 
** MBASIC is a Copyright of Microsoft, Inc. 

Note: ULC-OPSnet supports dBASE-II in a multi-user environ- 
ment with dBASE-II version 2.4 and above onJL]£. 
Previous versions of dBASE-II will not load and run 
properly over ULCnet. 
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and (provided the proper Privilege Levels are assigned) may be 
accessed by any node. The foreground partition of a node on the 
Net only has access to the File Control Block and the data con- 
tained in a file located on some other node. Thus, ULC-OPSnet 
utilizes the last byte of the filename extension to determine 
whether a file is locked by another user (.DBU if unlocked, .DBL 
if locked). Since memory locations 40H-4FH are normally set to 
00H (these 16 bytes in page of memory are not used by CP/M), 
ULC-OPSnet assumes that when accessing a file with a .DBU exten- 
sion, even if only to PIP the file , the user is opening the file 
with the intention of reading and writing to the file. Thus you 
will notice that when PIPing files with the .DBU physical file 
extension, the file at the destination will be stored with a .DBL 
file extension. It is necessary to rename files with the .DBL 
file extension to a .DBU extension before your application will 
properly handle the file. 
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RESTRICTED ASCII CHARACTERS AND FILE NAMES IN ULC-OPSnet 

ULC-OPSnet uses some ASCII characters as special switches 
and delimiters. The / character, for example, is used to denote 
an option switch for the DIR and QUEUE commands. It is important 
to note which of these ASCII characters cannot be used in file- 
names. If filenames already exist with restricted characters as 
part of the filename, the filename must be changed to utilize 
non-restricted characters. Otherwise, the file will not be found 
by ULC-OPSnet when accessed. 

The table below lists the complete set of ASCII characters 
with the corresponding hexadecimal values. Characters which 
cannot be used in filenames are in BRACKETS ([]). 



.+ +. 

: HEX : 



.+ +. 

: HEX : 



-+ +- 

: HEX : 



+ + 

: HEX : 

+ + 

60H 
61H 
62H 
63H 
64H 
65H 
66H 
67H 
68H 
69H 
6AH 
6BH 
6CH 
6DH 
6EH 
6FH 
70H 
71H 
72H 
73H 
74H 
75H 
76H 
77H 
78H 
79H 
7AH 
7BH 
7CH 
7DH 
7 EH 
7FH 



CHAR 



CHAR 



CHAR 



CHAR 



Cnul] 


: 


00H : 


[SP] 


[CTL Al 


: 


01H : 


[I] 


[CTL Bl 


: 


02H : 


["] 


[CTL CI 


j 


03H : 


[#] 


[CTL Dl 


; 


04H : 


$ 


[CTL e; 


: 


05H : 


[%] 


[ctl f; 


: 


06H : 


[&] 


[CTL Gl 


i 


07H : 


['] 


[ctl h; 


: 


08H 


i [(] 


[CTL i; 


: 


09H : 


[)] 


[CTL J] 


: 


0AH 


. [*] 


[CTL K] 


: 


0BH 


i [ + ] 


[CTL Li 


: 


0CH 


i C.3 


[CTL m: 


; 


0DH 


i [-] 


[ctl n; 


: 


0EH 


. [•] 


[ctl o; 


: 


0FH ! 


[/] 


[CTL P' 


: 


10H 


: 


[ctl q; 


: 


11H : 


1 


[ctl r; 


: 


12H : 


2 


[ctl s; 


: 


13H : 


3 


[ctl t; 


: 


14H 


4 


[CTL u: 


s 


15H 


i 5 


[CTL VI 


: 


16H 


: 6 


[CTL w; 


[ j 


17H 


: 7 


[CTL x: 


j : 


18H 


: 8 


[CTL Yl 


: 


19H 


: 9 


[ctl z; 


| : 


1AH 


: [:] 


[ESC] 


: 


1BH 


: [;] 


[FS] 


: 


1CH 


: < 


[GS] 


: 


1DH 


: [=] 


[RS] 


: 


1EH 


: > 


[US] 


: 


1FH 


: [?] 



20H 
21H 
22H 
23H 
24H 
25H 
26H 
27H 
28H 
29H 
2AH 
2BH 
2CH 
2DH 
2EH 
2FH 
30H 
31H 
32H 
33H 
34H 
35H 
36H 
37H 
38H 
39H 
3AH 
3BH 
3CH 
3DH 
3 EH 
3FH 



@ 
A 
B 
C 
D 
E 
F 
G 
H 
I 
J 
K 
L 
M 
N 

P 
Q 
R 
S 
T 
U 
V 
W 
X 
Y 
Z 
[ 
\ 
] 



40H 
41H 
42H 
43H 
44H 
45H 
46H 
47H 
48H 
49H 
4AH 
4BH 
4CH 
4DH 
4EH 
4FH 
50H 
51H 
52H 
53H 
54H 
55H 
56H 
57H 
58H 
59H 
5AH 
5BH 
5CH 
5DH 
5EH 
5FH 



* 
* 

* 
* 

* 

* 
* 

* 
* 
* 
* 

* 
* 
* 
* 

* 
* 
* 
* 
* 
* 
* 

I * 

} * 
~ * 

[DEL] 



a 
b 
c 
d 

e 
f 

g 

h 
i 

j 

k 

1 
m 
n 
o 
P 

q 

r 
s 
t 
u 
v 
w 

X 

Y 
z 

{ 



(*) Automatically translated to (-20H) character; i.e. 
is automatically translated to A (41H) . 



a (61H) 
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In addition to the restricted characters in the table, .COM 
filenames are also restricted. Literal sub-sets of ULC-OPSnet 
system commands cannot be used as .COM file names. For example, 
if the system were asked to execute INIT.COM, the .COM file would 
never be seen by the system. Instead, ULC-OPSnet would execute 
the INITialize command. Likewise, ULC-OPSnet will load the COPy 
(PIP) command instead of the C0PY.COM program if you attempt to 
run COPY. Compare your .COM file names with the command summary 
in Chapter 9, and rename any conflicting filenames. Note that 
Chapter 9 lists each of the ULC-OPSnet commands with the minimum 
command entry in CAPS and the remainder of the command in lower 
case. For example, the minimum entry for the WHERE command is W. 
Thus if you have files named W.COM, WH.COM, WHE.COM, WHER.COM or 
WHERE.COM, all must be renamed. Any one of the above entries 
will execute the WHERE command. 

OPERATIONS WITH OSUB.COM, OXSUB.COM, AND PSUB.COM 

The ULC-OPSnet equivalent of SUBMIT.COM and XSUB.COM are 
0SUB.COM and 0XSUB.COM respectively. PSUB.COM is a special relo- 
catable form of SUBMIT.COM that does not handle submit operations 
in the same way as CP/M's SUBMIT.COM, but may be used to execute 
a submit string within an application. Its primary function is 
to facilitate the submitted assignment of the LST: device to a 
file name while in an application like WORDSTAR. Operations with 
0SUB.COM and 0XSUB.COM are , however, handled in the same way as 
submit operations with the CP/M counterparts - with the following 
enhancements ; 

1. 0SUB.COM and 0XSUB.COM do not require additional memory 
to process submitted files. 

2. 0SUB.COM may be called with (a) <A0>SUBmit <filename> 
<param>....<param><RET> or (b) <A0>OSUB <filename> <param>.. 
. . <param> <RET> . 

3. 0XSUB.COM may be invoked with (a)<A0>OXSUB 0N<RET>, 
(b)<A0>XSUB ON<RET>, or simply (c)<A0>X ON<RET> . 

4. $$$.SUB files are created and processed in the same 
manner, as SUBMIT.COM processes these files in CP/M, except 
that all legal ULC-OPSnet commands may be embedded in the 
command file to be submitted, with the exception of the USER 
command . 

5. If a file named INITIA.INI exists on the system disk 
(A:) in the respective USER [ID] area at the time of LOGIN, 
0SUB.COM will automatically create and process a $$$.SUB 
file with the contents of INITIA.INI. 

6. The file extension .SUB is not required on the file to 
be submitted. 

7. 0SUB.COM and 0XSUB.COM may be used interchangeably 
between CP/M and ULC-OPSnet. SUBMIT.COM and XSUB.COM will 
not work under ULC-OPSnet, however. 
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OTHER PROCEDURAL AND OPERATIONAL CONSIDERATIONS WITH ULCnet 

The RETRY command is used to increase the number of network 
access retries prior to outputting the console message: 

?Node x unavailable - Retry (Y/N)? 

...where Node x is the physical location of a virtual disk 
currently being accessed. ULC-OPSnet utilizes a complex algo- 
rithm to determine the optimum number of packet retries prior to 
printing this message. Among the components of the algorithm are 
relative network activity, division of processor time between 
foreground and background, and whether the uncompleted request at 
Node x was for a read or a write. Clearly, once the message is 
outputted to the console, foreground processing stops until the 
operator intervenes and makes a decision. A "N" answer will 
abort the current task and return the CCP. A "Y" answer will 
restart the RETRY algorithm and continue current task execution 
if the packet I/O is successful. 

The algorithm provides successful results for most cases, 
i.e., if the "time-out" retry message appears, it is usually 
because something is wrong at the location of Node x, and alerts 
the operator to inquire prior to proceeding. In the case of 
unattended operation (a large database sort or backup, for ex- 
ample), the operator may want to set the RETRY counter prior to 
proceeding. This is accomplished through the RETRY command. The 
command syntax is: 

<A0>RETRY <0-127><RET> 

RETRY is also an Information Command: 
<A0>RETRY<RET> 

...returns the current value in the RETRY counter. Remem- 
ber, setting the RETRY counter sets the num ber of iterative 
executions of the RETRY algorithm, and not the physical number of 
retrie"sT For example, suppose the average elapsed time for tn~e 
RETRY algorithm is 30 seconds prior to "time-out". If the RETRY 
counter were set to 10, the system would take approximately 5 
minutes continually attempting to send the packet prior to print- 
ing the "time-out" message. 

Another operational consideration that must be discussed is 
the use of the SEND command. ULC-OPSnet uses a less complicated 
packet verification procedure in message communications than it 
does in disk I/O and spooling functions. Since message communi- 
cations are "non-critical", system overhead is reduced signifi- 
cantly by this simplified procedure. In instances of high net- 
work activity, however, a console message sent to a particular 
Node with the SEND command m ay appear at the receiving Node 
more than once. Since SEND to a particular Node requires an 
acknowledgement at the sending Node, high network activity can 
create a situation where the sending Node retransmits the message 
prior to acknowledgement by the receiving Node. This situation 
will not occur in networked file transfer or spooling operations. 
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ADDITIONAL XBDOS CALLS IMPLEMENTED IN ULC-OPSnet 

ULC-OPSnet utilizes the standard CP/M BDOS (Basic Disk Oper- 
ating System), and additionally, implements an Extended BDOS 
(XBDOS) required for networking operations. Many of the calls in 
XBDOS are available to applications suppliers and assembly lan- 
guage programmers for use in creating or altering applications 
for optimum performance in the ULCnet environment. The available 
XBDOS calls, purpose, and resulting return codes are documented 
as follows: 

1. Function 100 - Return address of USER Block 
On call: C = 100 

On return: HL = USRBLK: address 

HL-2 = Retry Setting (decimal 0-127) 

HL-1 = OVON/OFF switch ('N'=On, 'F'=Off) 

HL = User [ID] binary 

HL+1 = User's name in ASCII (9 bytes) 

HL+10= User's displayed Privilege Level 

HL+11= Extended Privileges (2 bytes) 

This call may be used to inquire or set the OVON/OFF flag, 
inquire or change the retry counter, or to get useful infor- 
mation about the user. 

2. Function 101 - Initialize System 

On call: C = 101 

On return: Control is returned to ULC-OPSnet and disk system 
is initialized with CP/M BDOS call 13. 

This is functionally equivalent to exiting through the INI- 
TIALIZE command. 

3. Function 102 - LOGOUT User 

On call: C = 102 

On return: User is no longer logged into system, Virtual 
Device table is reinitialized to local A: and B: drives, 
Retry Counter is reset to '0', XSUB is turned off, User 
Privilege Level is reset to '0', User status is reset to 
'0', disabling foreground processing until a new successful 
LOGIN is executed. 

Upon return the user will no longer have any system access 
privileges. Upon exit the user is required to execute LOGIN 
again before using the system. 



8-9 



4. Function 103 - Return Address of QUEUE Block 
On call: C = 103 

On return: HL = Address of QUEBLK: 

HL = Pointer to contiguous 36 byte FCBs 
Format of the FCBs are standard except for the following: - 

FCB+12 = Upper 4 bits = if normal forms or non-0 for 

special forms 

Lower 4 bits = Number of copies to be queued 
FCB+13 = User number of file to be queued 
FCB+14 = Physical device of file 
FCB+15 = Node address of file (0 = Local or ASCII node - 

'0* ASCII) 

This function may be used to check the queue data or to 
enter a queue request. 

5. Function 104 - Process Command 

On call: 0080H = Standard console buffer format 

This function processes an ULC-OPSnet command and returns to 
the program. 

NOTEs Use of this call requires that TPA not be destroyed 
unless the application program is loaded outside of the 
" danger zone " . 

6. Function 110 - Return Gatekeeper Information. 

On call: C = 110 

On return: A = 123 if Gatekeeper or other if workstation. 
HL = Pointer to GTAB 

This function is useful to determine if a station is a 
Gatekeeper or a Workstation. 

7. Function 120 - Return Network Vector Block 
On call: C = 120 

On return: HL = Network vector block address 

HL thru HL+11 = RESERVED (Do NOT change) 
HL+12 = Node ID (ASCII node - '0' ASCII) 
HL+13 = for ASYNC, 1 for SYNC 

This function may be used for obtaining the Node ID. If the 
Node ID is 80h+'0' then the station is not INETed and ULCnet 
access is denied. To translate the node ID into ASCII, add 
an ASCII '0' to the Node ID. ASYNC or SYNC mode may also be 
obtained but NOT changed I 
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8. Function 124 - Send a Packet 

On call: A = 2 

C = 124 

HL = Packet address 

This function will transmit a packet over ULCnet. 

9. Function 125 - Receive a Packet 

On call: C = 125 

On return: A = Return code 

HL = Address of the received packet 

Return codes: ... Good packet 

1 ... Bad packet 

2 ... No packet - Time out 

This call receives a packet into an ULC-OPSnet buffer and 
returns the packet buffer address and the completion code 
(Return code). If Return code "1" is encountered, try a re- 
receive; if Return code "2", then try from 1 to 25 re- 
transmission retrys (as a function of the priority of the 
operation) before failing. 

10. Function 126 - Return Disk Assignment Table 

On call: C = 126 

A = Logical disk number 

On return: HL = Pointer to assignment vector 
HL = Physical disk number 
HL+1 = Location (Node id) of disk 

This function is useful in checking assignments or making 
assignments. The physical disk is for not assigned or the 
physical number (A:=l, B:=2,...) if assigned. The location 
is for local or the Node ID if remote. 

11. Function 127 - Return Last Command Issued 
On call: C = 127 

On return: HL = Pointer to an image of the last command buffer 

This function points to an image of the command buffer. 
Hence it is possible to DMA to 0080H and later still find 
the command line. 
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12. Function 128 - Set Spooler Location 

On call: C = 128 

A = Node id of spooler, = local 

This function changes the path of the QUEUE service to 
either the local device or a remote device. 

13. Function 130 - Get Spooler Location 
On call: C = 130 

On return: A = Node ID of current spooler 

This call returns if the spooler is local or the remote 
Node ID if the spooler has been assigned to a remote Node. 

These calls should only be used by experienced programmers. 
Careful attention must be paid to specific memory locations which 
if used, may generate unpredictable results. Used as documented, 
XBDOS, in combination with OSUB, OXSUB, File Lock, and the entire 
ULC-OPSnet security scheme, form the base of powerful application 
potential in a truly distributed processing environment. 

XBDOS CALL EXAMPLES 

The following is an example of how an application (or sys- 
tem) program can enter a file into the print queue. 

7 CALL CONVENTION EXAMPLE: 



LD 


HL,FCB2QU 


LD 


DE,FCB1 


LD 


BC,16 


LDIR 




LD 


A, (COPIES) 


AND 


10H 


CALL 


QUE IT 


AND 


A 


JP 


Z,QOK 


CP 


1 


JP 


Z , QFORB 


JP 


QFULL 


On entry: 





FCB TO QUEUE 

ROUTINE USES FCB1 

ONLY FIRST 16 BYTES 

TRANSFER 

PLACE # OR COPIES IN A 

IF SPECIAL FORMS 

ENTER INTO QUEUE 

ANY ERRORS? 

NO, OK 

REMOTE BUSY OR QUEUES FULL? 

YES 

ELSE QUEUES ARE FULL 



THE FCB TO QUEUE IN FCB1 : 

IN THE HI 4 BITS OF A ZERO FOR NORMAL FORMS OR ONE FOR SPECIAL 

IN THE LO 4 BITS OF A THE NUMBER OR COPIES-1 (I.E. = 1 COPY) 



Upon return: 

A = - Queue was entered. 
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A = 1 - Remote station was busy or unavailable, also occurs if 

the remote station's queues are full. 
A = 2 - The local queues are full. 



********************************************** 

* SET FORMS AND COPIES * 

********************************************** 



QUEIT: LD 



(FCB1+12),A 



;SET FORMS AND COPIES 



********************************************** 

* DECIDE TO QUEUE LOCAL OR REMOTE * 

********************************************** 



LD 


C, 81H 


CALL 


BDOS 


AND 


A 


JP 


Z , QLOCAL 



7 CALL 129 - GET SPOOLER LOCATION 

;GET SPOOLER LOCATION 

;TEST A FOR ANY BITS ON 

;IF A = IT'S LOCAL - ENTER QUEUE 



********************************************** 

* SET UP PACKET FOR TRANSMISSION * 
********************************************** 



7 WHERE TO GO 






LD 


(PDEST) ,A 


;WHAT 


FILE 






LD 


HL,FCB1 




LD 


DE , PDATA 




LD 


BC,16 




LDIR 




;WHAT 


USER 






LD 


E,0FFH 




LD 


C,32 




CALL 


BDOS 




LD 


(PUSER),A 


7 WHAT 


PHYSICAL 


DEVICE 




LD 


A, (PDATA) 




LD 


C07EH 




CALL 


BDOS 




LD 


A, (HL) 




LD 


(PDATA) ,A 



7 PRIME PACKET FOR SENDING WITH 
7 DESTINATION NODE ID 



7FCB1 IS TO FILE TO BE QUEUED 
7 MUST BE PLACED IN PACKET DATA 
7 ONLY FIRST 16 BYTES 
7 PLACE FCB IN Q REQ PACKET 



;E MUST BE 0FFH TO RETURN USER 

7 CALL 32 - GET/SET USER # 

7 FETCH OUR USER # 

7 SAVE USER ID IN PACKET 



7 FETCH LOGICAL DEVICE FILE IS ON 

7 CALL 126 - DEVICE TRANSLATE 

7 CHANGE LOGICAL TO PHYSICAL DEVICE 

7 FETCH PHYSICAL DEVICE 

7 REPLACE WITH PHY DEV: 



7WHERE THE FILE IS TO PRINT 
INC HL 
LD A, (HL) 
AND A 
JR Z , RESEND 



LD 



(PSOURC),A 



7 BUMP TO DEVICE LOCATION 

7 GET NODE ID OF DEVICE 

7 TEST A FOR ANY BITS 

7 IF LOCAL OPSNET WILL PLACE OUR 

7 NODE ID IN AUTOMATICALLY 

7 IF REMOTE OVERRIDE WITH REMOTE NODE 

7 ID SO THE SPOOLER WILL LOOK THERE 
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, ********************************************** 

* TRANSMIT PACKET AND WAIT FOR ACK * 
********************************************** 



XOR 


A 


LD 


(RTRY),A 


RESEND: LD 


A, 2 


LD 


C,07CH 


LD 


HL, PACKET 


CALL 


BDOS 


RERCV: LD 


C,07DH 


CALL 


BDOS 


CP 


1 


JR 


Z , RERCV 


CP 


2 


JR 


NZ , CHKACK 


LD 


A, (RTRY) 


INC 


A 


LD 


(RTRY) ,A 


CP 


5 


JR 


NZ , RESEND 


LD 


A,l 


RET 





RTRY: 



DEFB 



?ZERO A 

;ZERO RETRY COUNTER 

ySTX PROTOCOL 

7 CALL 124 - SEND PACKET 

7 POINT AT BUILT PACKET 

7 TRANSMIT IT OVER THE NET 

;CALL 125 - RECEIVE PACKET 
; GET ACK 

;ADR PROBLEM? 

;YES, WAIT 

;TIME OUT? 

7 NO, GOOD PACKET - GO CHECK IF ACK 

7 GET RETRYS 

7 COUNT ANOTHER 

7 UPDATE 

7 TOO MANY? 

7 NO, RETRY 

7 FLAG QUEUES FULL OR OTHER NODE BUSY 
7 RETRY COUNTER DEFINITION 



********************************************** 

* ACK PACKET CAME MAKE SURE IT'S CORRECT * 
********************************************** 



CHKACK: 


LD 


DE,7 




ADD 


HL,DE 




LD 


A f (HL) 




CP 


103 




JR 


NZ , RESEND 




XOR 


A 




RET 





7 ADD OFFSET FOR PACKET TYPE 

7 GET PACKET TYPE 

7 ACK? 

7 NO, TRY AGAIN 

7 GOOD QUEUE 

7 DONE, RETURN TO CALLER 



********************************************** 

* SECTION TO ENTER A LOCAL QUEUE REQUEST * 
********************************************** 

QLOCAL: LD C,67H 7CALL 103 - GET QUEUE BLK ADR 

CALL BDOS 7 FETCH FIRST QUEUE ENTRY ADDRESS 

7 IN PAIR HL 
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********************************************** 

* FIND AN EMPTY QUEUE ENTRY * 

********************************************** 



FINDQ: 



PUSH 


HL 


INC 


HL 


LD 


A, (HL) 


AND 


A 


JR 


Z , QFULL 


CP 


20H 


JR 


Z , ENTERQ 



POP 


HL 


LD 


DE,24H 


ADD 


HL,DE 


JR 


FINDQ 



SAVE IN CASE THIS ONE IS EMPTY 

BUMP TO FILENAME OF QUEUE 

FETCH 1ST CHR OF FILENAME 

TEST ANY BITS IN A 

END OF LIST, QUEUES ARE FULL 

EMPTY ENTRY? ************** 

YES, GO ENTER QUEUE * NOTE: ADR * 
********************* * 

* OF EMPTY ENTRY PUSHED ON STACK * 
********************************** 

NOT THIS ONE 

;BUMP TO NEXT ONE 
;KEEP LOOKING 



********************************************** 

* MODIFY FCB FOR QUEING AND ENTER THE QUEUE * 
********************************************** 



: LD 


E,0FFH 


LD 


C,32 


CALL 


BDOS 


LD 


(FCB1+13),A 


LD 


A, (FCB1) 


LD 


(FCB1+14),A 


XOR 


A 


LD 


(FCB1+15) ,A 


LD 


HL,FCB1 



QFULL: 



POP 



DE 



LD 


BC,16 


LDIR 




XOR 


A 


RET 




LD 


A, 2 


RET 





0FFH MEANS RETURN USER # 

CALL 32 - GET/SET USER # 

GET USER ID 

SAVE USER ID IN FCB FOR QUEUER 

FROM DISK WHATEVER 

SAVE LOGICAL DISK FOR QUEUER 

LOCAL IS ZERO IN A 

TELL QUEUER IT'S A LOCAL REQUEST 

POINT AT FCB TO QUEUE 
******************************** 

****** p p QENTRY ADDRESS ****** 
******************************** 

ONLY 16 BYTES NEEDED 
QUEUE FILE LOCAL 
GOOD RETURN CODE 
BACK TO CALLER 

; QUEUES ARE FULL RETURN CODE 
;BACK TO CALLER WITH BAD NEWS 



********************************************** 

* SKELETON OF QUEUE REQUEST PACKET * 
********************************************** 



PACKET : 


DEFB 





PDEST: 


DEFB 


0,0,0 


PSOURC: 


DEFB 


0,0,0 


PTYPE: 


DEFB 


102 


PLEN: 


DEFW 


19 


PDATA: 


DEFS 


16 




DEFB 


0,0 


PUSER: 


DEFB 






; REQUEST PACKET 

;ADR OF SPOOLER 

;OUT ADR 

;THIS IS A QUEUE REQ 

; LENGTH OF DATA 

; QUEUE REQUEST DATA 

;USER ID OF REQUESTER 
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CHAPTER 9 
SUMMARY OF COMMANDS AND ERROR MESSAGES 



COMMAND SUMMARY 

The command structure of ULC-OPSnet is very similar to 
CP/M's command structure. "TSP's", or Transient System Proces- 
ses, overlay the contents of TPA; "RSP's", or Resident System 
Processes, are commands which remain memory resident and do not 
affect the program in the TPA. Some of the TSP's are contained 
in the generalized utility modules, UTIL.COM and NETUTIL.COM. 
Others, like SEND.COM, QUEUE.COM and L0G.COM, are stand alone 
programs which will run only under the control of ULC-OPSnet. 
The major differences between CP/M commands and ULC-OPSnet com- 
mands are: 

1. ULC-OPSnet has many more commands than CP/M. 

2. CP/M commands are enhanced to run in the network 
environment. 



CLASSIFICATION OF COMMANDS 

ULC-OPSnet supports three types of commands: 

1) The General Commands. 

2) The Enhanced CP/M Commands. 

3 ) The Network Commands . 

The General Commands are subdivided into: 

1) The queue/ spool commands. 

2 ) The information commands . 

3 ) The system commands . 

The queue/ spool commands are: 

ASSIGN LST: - Assign the LST: device to a disk file. 

FINISH - Finish (close) the disk file the LST: 

was assigned to. 

QON - Enables printing from remote stations . 

QOFF - Disables printing from remote stations. 

QUEUE - Queuer/spooler control. 

SPOOL - Assigns node address for spooled output 

The information commands are: 

CORE - Tests and displays the available TPA. 
FIND - Finds the logical disk location of 

file(s) requested from assigned disks. 
OHELP - Displays help information on commands. 
WHO - Displays information about other nodes 

on ULCnet. (Gatekeeper command) 
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The system commands are: 



GET 

INITIALIZE 

LOGIN 

LOGOUT 

OVOFF 

OVON 

PROTECT 

QUEUE 

REACT 

R 

RUN 

START 
TTY 

ULCOPS 
ULCOPSG 



Loads a .COM program file. 
Initializes (resets) the disk system. 
Gain access to ULC-OPSnet. 
Give up access to ULC-OPSnet. 
Turns off automatic .OV? search. 
Turns on automatic .OV? search. 
Change file attributes. 

Assigns USER [ID]'S, Passwords, and Priv- 
ilege Levels. 

Run a .COM file from system area of a 
Named disk. 

Run a .COM file in user area of a Logged 
disk. 

Executes last .COM program loaded. 
Set terminal parameters for message 
display. 

Loads the Workstation operating system. 
Loads the Gatekeeper operating system. 



The Enhanced CP/M Commands are: 



COPY-tPIP) _ 

d: 
DIR 
ERA 
OSUB 



PSUB 

OXSUB 

RENAME 

SAVE 

STAT 

SUBMIT 

TYPE 

USER 



Peripheral Interchange Program; oper- 
ates on physical and logical devices. 
Change default (logged) disk. 
Displays file directory information. 
Delete file(s) . 

Group commands (submit) for batch 
processing. EquivalenttoCP/M 
SUBMIT.COM. 

SUBMIT COMMAND which may be used 
within Wordstar. 

Obtain variable parameters for submitted 
commands from command line. 
Renames a file. 

Saves user memory image to .COM file. 
List system statistics, 
(same as OSUB) . 
Type file to CRT. 
Change user areas. 



The Network Commands are: 



ASSIGN 

INET 

LOCATE 
MAIL 

SEND 

SPOOL 
WHERE 



Assign, reassign or deassign disk 

devices. 

Initializes network and assigns 

node ID. 

Changes logical station location. 

Transmits file to remote station's 

MAIL file in named USER [ID]. 

Transmits message to remote console 

device. 

Selects station for spooling operations 

Displays device assignments and 

locations . 
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Forms and examples of each command follow; 



ASSign A: 

ASSign C:=G: 

ASSign D:=A:5 

ASSign LST : =D : F00 . LPT 



CORe 

COPy A:DOG=C:CAT 



;Deassigns A: 

; Reassigns C: to be G: locally 
;Assigns D: to physical A: on node 5 
;Assigns allLST: output to file 

DrFOO.LPT 
;Use the FINish command to close the 

file and assign LST: to LST: 

; Display available TPA 



;Copy CtCAT to A: and name it DOG 
COPy XX.FUN=C:FOO, F:XX 7 Copy C:FOO, then F:XX to A: and name 

entire file XX. FUN. 



Directory 
Directory A: 
Directory *.COM 
Directory *.DOC/W 

Directory B:/P 
ERase B:*.BAS 
FIND *.ASM 

Finish 

Get EDITOR 
INET XEROX 8 
INET KAYPRO K 
INET TV 3 

Initialize 



LOCate 
LOCate 7 

LOGin 7 



LOGout 

MAIL 

MAIL 52 A: LETTER 

MAIL 7 A:LETTER 

USERCID] 



;Show all files on the default disk 
;Show all files on disk A: 
7 Show all .COM files on the default disk 
7 Show a detailed directory for all .DOC 

files 
7 Show all files on disk B: and Print 

the directory locally 

7Erase all files on logical B: disk with 
the extension .BAS 

7 Search the active USER [ID] of all disk 
drives currently in WHERE table for all 
files with the .ASM extension 

7Closes spooled LST: file and assigns 
LST:= [Current I/O Byte] 

7 Load EDITOR.COM into the TPA 

7 Initialize network for a XEROX computer, 
node 8 

7 Initialize network for a KAYPRO corn- 
computer, node K 

7 Initialize network for a TELEVIDEO 
computer, node 3 

7 Reinitialize the disk system? used when 
changing diskettes (BDOS call 13) 

7 Locate devices local 
7Locate devices at node 7 

7 Login to system as user 7 (Password 
required) 

7 Give up access to the system 

7 Check mailbox 

7 Mail A: LETTER to node 5, USER [2] 

7Mail A:LETTER to node 7, Sender's 
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OHelp or H 
OHelp or H * 
OHelp or H ASSIGN 

OSUBmit JUNKDIR 

SUBmit X.X A B C 

PSUB PRINTON 

OVOFf 
OVON 



PROtect MYFILE RO 
PROtect A: FILE LOCK 

QUeue 

QUeue FILE. LPT 

QUeue CRT: 

QUeue ULl:=FOO.LPT 

QUeue/Abort 

QUeue/Eject 

QUeue C:MYFIL/C3 

QUeue H:TACOS/F 

QOFf 
QON 



R PIP 

R H:WS 

REACT 

REName XYZ=ABC 

RUn FOO 

SAVE 6 B: XYZ.COM 



SEND 1 MESSAGE 
SEND AL1 MESSAGE 

SPool 
SPool 

SPool 5 



7 Displays this text 

7 Displays all subjects available 

7 Gives information on the ASSIGN command 

; Submit JUNKDIR. (or if not found 

JUNKDIR. SUB) 
; Submit X.X with A, B, and C for 

arguments 
; SUBMIT PRINT ON. SUB 

;Turn off automatic .OV? search 
;Turn on automatic .OV? search (default 
condition at LOGin) 

; Protect MYFILE Read/Only 
7 Lock A: FILE 

7 Display queues and spooler status 

7 Print FILE. LPT to default queue device 

7 Set spooler device default to CRT: 

7 Spool FOO. LPT to device UL1 : 

7 Stop current file from spooling 

7 Set printer to top of form 

7 Spool C:MYFIL and make three copies 

7 Spool HrTACOS and set special forms 

message at current spooler node 
7 Turn off background spooler? print local 
?Turn on background spooler? (default 

condition at LOGin) 

? Run the PIP.COM program from the logged 
disk, active USERf irst, then search 
the A: disk, USER [0] 

7 Run the WS.COM program from the H: disk 

? Establish or reset Passwords, Privilege 

Levels and USER [lD]*s 
7 Rename file ABC to XYZ 

7 Run the F00.COM program looking to the 
default disk, active USER [ID] first, 
then looking to the A: disk, USER [0] 

;Store the contents of the first six 
records (128 bytes each) of the TPA on 
drive B: and name it XYZ.COMx 

? Send a message to node 1 
7 Send a message to all nodes 

7 Displays spooler location 

;Use local spooler and locally attached 

list device 
?Use spooler at node 5 andlist device 

attached to node 5 
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STart 

STart APPLE PEAR 



TTy Crt 
TTy Gag 
TTy No Gag 
TTy Tty 

TYpe JtMYFILE.DAT 



; Start execution of the program in the 

TPA 
7 Start with APPLE and PEAR program 

arguments 

; Terminal is a CRT 
;Don't receive messages if busy 
; Receive a message any time 
; Terminal is a teletype 

; Display the contents of JtMYFILE.DAT on 
the CRT 



User 
User 7 

Where 
Where C: 

WHO 



Xsub ON 
Xsub OFF 



; Display current user information 

; Change user number to 7 (If privleged) 

; Display device assignments 
;Display C: assignment and location 

; Display information about each node at 
the Gatekeeper 

7 Turns on OXSUB [XSUB active] 
;Turns off OXSUB [XSUB inactive] 



ERROR MESSAGES 

ULC-OPSnet displays a number of error messages under a 
variety of conditions. These messages together with the probable 
causes are discussed in this chapter. 

One class of error message relates to a .COM file not being 
found physically on a disk. The message: 



?< Program name>? 



is generated when ULC-OPSnet attempts to call a certain program 
(.COM file) from the disk and is unable to locate that program. 
Immediately take a directory of the system disk (drive A:) and 
verify that the particular program name is resident if not, 
insert the system disk which came with this manual in drive B: 
and take a directory. If the program is on the drive B: direc- 
tory, make up a new system disk with both the CP/M files and the 
ULC-OPSnet files (refer to Chapter 3). The new system disk should 
remedy the problem. If the particular program is missing from the 
original ULC-OPSnet system disk, consult your dealer. 

The following list describes the most common error messages 
and their probable causes. 



MESSAGE 



PROBABLE CAUSES 



% Node <ID> is busy 
or unavailable. 



1. TTY GAG was set at receiving 
station. 
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MESSAGE 



PROBABLE CAUSES 



Retry (Y/N)? 



2. CPU is unavailable (bound) at 
the instant the message was 
sent. 

3. Receiving station is not 
physically connected to network. 

4. Receiving station has not 
initialized network with INET. 



?NET NOT READY 



Transmitting station is not 
physically connected to network, 
Transmitting station has not 
initialized network with INET. 
Hardware failure. 



?Device X not assigned 



A non-assigned device has been 
specified. 



?Unknown system type 



Incorrect computer type specified 
in an INET command. 



?File protected 



Displayed when an attempt is made 
to access a file which is protected 
as private or has been locked and 
is open. 



?No such file(s) as 
<file name> 

?Bad user number 

-or 
?Bad user # 



Displayed if specified file does 
not exist. 

Displayed if user ID is not in the 
range to 9 upon LOGIN. 



?Not privileged 



Displayed if an attempt is made to 
access a file by a non-privileged 
user . 



% Directory is empty 
for DSK <disk ID: 
[User ID]> 

?No such files on DSK 
<disk ID: [user ID]> 



Displayed if an attempt is made to 
take a directory of an empty 
diskette. 

Displayed when an attempt is made to 
take a directory for a specific file 
and that file is not found. 



?Bad < switch/ switches > 



Displayed when a switch other than a 
"P" or "W" is specified in the DIR 
command or other than "C" , "F" , "A" 
or "E" is specified with QUEUE 
command . 



?Too few arguments 



Displayed when an insufficient 
number of arguments are specified 
for a given command. 
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MESSAGE 



PROBABLE CAUSES 



% No info on <subject> 



Displayed if a HELP command is 
entered with a subject for which 
help is not available. 



?Invalid password ■ 
Please LOGin again 

< TTY>< argument >? 



BAD LOAD 



Displayed if an invalid password 
is entered. 

Displayed if an invalid argument 
is entered with a TTY command. 

Displayed if the CP/M system 

is too small to hold ULC-OPSnet. 



?The queues are full 



Displayed if an attempt is made 
to print a file when all 4 queues 
are full. 



PCannot print a binary 
file 



Displayed if an attempt is made 
to print a binary file (normally 
those with a .BIN or .COM 
extension) . 



PDevice <Dev:> cannot 
be spooled 

%Dir Error 



Displayed if an invalid device was 
specified for printing. 

Displayed whenever network traffic 
causes incomplete or erroneous 
directories . 



?Invalid file attribute 



?Disk or directory 
full 



Displayed when the Protect command is 
used with a wrong attribute. 

Displayed when the selected disk is 
full. 



?Form is: 'MAIL' or 
' MAIL<node><user> 
<f ile spec> ' 

?Login please 



Displayed when MAIL is used with the 
wrong attributes . 



Displayed when an attempt is made to 
use ULC-OPSnet without logging in. 
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Figure 2-1. Making a Terminated Tap Socket. 
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Figure 2-2. Placing a RJ-11 Tap Socket into the Network. 
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Figure 2-3. Installing the Network Circuit Board. 
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Figure 3-1. Write Protection for a 5%" Diskette. 
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